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INTRODUCTION 


'g  tv\L'Xii l\.  e rcrt  is  primarily  documented  by  this  report,  plus  tvo  other 
do  cl  ' - MUXSiM  User's  Manual  (ref.  1)  and  the  MUXSIM  System  ModiD  cation 

•esi,  y al  'ref.  2'  References  1 ond  2 provide  derails  of  how  to  use  a. id  hov- 

■;o  modify  M esnectively.  Only  summaries  of  this  kind  o information  are 

it  . . 7 main  body  o?  this  report  is  directed  to  present  a broad  overview 

o.  cr.:  ..  or  . h sr.  'hosts  on  highlights.  However,  a considerable  amount  or 

( n d-r-U.r.  specifics,  history,  rationale,  etc.  will  be  found  in  the  appendices  tc 
rins  document. 


lire  erf  art  vas  divided  into  four  phases: 

P'  ase  I - Definition 
•>  Phase  II  ~ Design 

Phase  iii  -•  Implementor’on 
o Phase  IV  - Operational  Evaluation  Database 

The  per  inent  results  and  particulars  of  the  first  three  phases  are  contained 
in  the  body  o;  rr. . Report  and  in  Appendices  A and  B.  The  fourth  phase  was  pert  of  c 
*.  distinct  effort  and  was  documented  in  a Technical  Report,  "Data  Su^ric y 
IDA, AST  Baseline  Avionic  Su;*e,  1 dated  17  February  1976  (ref.  9).  Additional  details 
may  be  four  : in  he  MUXSiM  Technical  .Notes  and  Interim  Reports  cited  in  Appendix  C 

MUXS.M  was  developed  to  fill  i e gap  between  manual  anolys  s rd 
r'oadb’.-ard  echriques  in  the  design  of  complex  multiplex  systems,  it  is  basically  a 
cor.  purer-aided  assign  tool  ‘.tended  especic  iy  for  simulation  of  multiplex  system  . 

As  such,  ir  cedes  tne  multiplex  system  designer  to  reduce  the  time  required  ;o  arrive 
or  an  opthrv.  assign,  and  enables  him  to  debug  his  designs  at  an  early  stage  to  reduce 
the  likelinood  of  costly  hardware  redesign  efforts  in  the  late  stages  of  the  development . 


MuXSl-V,  i;  nor  intended  to  replace  all  other  existing  tools  of  the  multiplex 
system  designer;  rather,  it  is  intended  to  supplement  and  complement  them.  Its  main 
purpose  may  be  stated  succinctly  as  follows: 

"To  me tj.  in  answering  rher  set  of  multiplex  system  de;  grer  s 'what  if  type 
questions  which  are  c ifficuit  or  impractical  tc  answer  accurate'  by  other  meens  one  io 

do  so  in  o cost-effec  ive  manner." 


1 


Among  the  critical  MUXSIM  design  decisions  were  the  following: 

• Decision  to  focus  MUXSiM  on  questions  asked  during  the  earlier 
phases  of  a typical  multiplex  system  design  effort  (for  maximum 
cost-effecti  veness) 

• Decision  to  focus  MUXSIM  on  questions  relating  to  the  multiplex 
system  architecture  and  organizational  levels  rather  than  on  detail 
levels  such  as  the  electrical  design  of  the  bus  (for  maximum 
cost-effectiveness) 

• Decision  to  make  MUXSIM  interactive  (for  ease  of  use) 

• Decision  to  make  MUXSIM  Fortran-based  (for  ease  of  development, 
ease  of  modification,  and  "portability") 

• Decision  to  use  GASP  as  a vehicle  for  implementing  dynamic 
MUXSIM  models  (for  ease  of  development,  and  generality) 

• Decision  to  emphasize  the  utility  subsystem  and  the  development  of 
real  workloads  for  driving  MUXSIM  models  (for  credibility  of  results 
and  realism) 

• Decision  to  make  MUXSIM  highly  modular  (for  ease  of  development 
and  flexibility) 


The  design  of  MUXSIM  utilized  mainly  a top-down  approach,  with  emphasis 
on  modularity;  however,  in  certain  instances,  a probe-coding  (software  breadboard)  ap- 
proach was  used  for  sizing  and  feasibility  studies.  The  rationale  for  all  of  the  MUXSIM 
direction  and  tradeoff  decisions  is  contained  in  this  report. 

Although  the  MUXSIM  design  and  implementation  effort  has  included  many 
evaluations  at  different  design  levels,  there  nas  been  limited  time  available  for  an 
operational  evaluation  of  the  completed  package  as  a whole.  However,  several  sample 
simulation  experiments  were  performed  as  part  of  the  MUXSIM  verification  effort  which 
are  thought  to  be  typical  of  those  which  might  be  performed  by  a multiplex  system  designer. 
The  results  of  these  experiments,  together  with  computer  resources  and  user  steps  required 
for  their  execution,  are  covered  in  the  report.  They  tend  to  indicate,  but  noT  to  prove, 
the  cost-effectiveness  of  MUXSIM. 

In  addition  to  MUXSIM's  primary  role  os  an  analysis  tool  for  use  in  early 
stages  of  the  multiplex  system  design  process,  several  MUXSIM  outputs  are  directly  useful 
in  later  stages  also.  In  fact,  some  of  these  outputs  can  be  used  directly  either  as  ini  tic  I 
production  aids  or  in  facilitating  modifications  to  production  systems,  such  as  m'ght  be 
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ec  vi  ,:r  .vit^n g or  augmenting  t..e  avionics  suite  for  an  cire.-oft.  For  example 

c«'T'  <>  oi  '■  jf4  aid  in  manufacturing  operations,  while  others  aid  in  multiplex  system 
50 i : eat.  Specific  examples  of  MUXSIM  benefits  of  different  types  ore 

include''*  in  me  oov  of  the  /epoit. 

rvo.  - : . ' 'ona * o.  user's  point  of  view,  MUXSIM  is  on  extensible  software 

sin. i , * ■ a k'  g».  •Aiiich  is  primarily  intended  as  a tool  for  the  multiplex  system  designer. 

:•  p-  - iy  y-.n  -r.tted  on  the  AFAL  DEC  System-10  under  the  TOPS- 10  operath  g 
system . There,  r •••"  interactively  for  maximum  ease  of  use  by  the  MUXSIM  Basic  Jr. - - 
- 'i'  MUXSIM  is  a rortr on-based  package,  it  is  quite  easily  moved  fro-  ~ne 

■sac.1'  • if  tin-  intended  new  host  system  has  a Fortran  compiler  and  c.  sui-.-Ie 
. vrat'  '.vsvem  A baten  version  of  MUXSIM  is  also  currently  operational  on  tlv. 
i rris  uo.ac.-jrt  Jj2h/j  system..  This  vet's  ion  exists  because  it  was  convenient  to  devexp 
MUXSIM  by  implementing  and  debugging  it  first  on  rhe  Datacraft,  followed  by  transfer 
to  ine  XFAo  DEC  Sysre  n-10  on  a module-by-moaule  basis. 

From  a logical  or  software  impiementer's  point  of  view,  MUXSiM  consists  of 
four  major  subsystems,  termed  the  Utility,  Static,  Dynamic,  and  Executive,  respectively, 
i ne  Uti'  subsvr-tcs  is  essentially  a data  base  management  system  for  MUXSIM,  where 
the  data  base  const  .?  of  one  cr  more  signal  flow  lists  which  characterize  the  information 
transfer  workload  to  be  accomolished  by  ‘he  multiplex  system  being  simulated.  The  St  ,i< 
subsystem  consists  of  the  RT  assign  work  map,  message  map,  fixed  format  scheduling  - 
fi  -ed  format  bus  loading  computation,  it  consists  of  eight  models  which  represent  »•  ' 
different  configmsKons  of  word/message  mopping.  This  subsystem  is  called  'sro  ‘c1  c*  .a  _ 
stochastic  events  are  not  explicitly  considered,  ana  because  dynamic  handling  cr  simuic  i 
rime  is  not  -equi*red.  Thus,  the  Static  subsystem  comprises  mainly  "steady-state " models 
of  u -,.j  ip  ex  system.  The  Dynamic  subsystem  consists  of  two  models  which  are  colled 
"dynamic1  because  stochastic,  events  characterizing  such  phenomena  as  multiplex  system 
corrnonent  failures,  bus  noise,  and  time-variable  data  transfer  requirement:  ere  e-.pU-.i'.iy 
considered,  This  system  is  quite  general,  because  it  incorporates  a comp  Set  3 dlscrA. 
even,  and  continuous  simulation  package  coded  GASP  iV  as  a component.  Both  Static 
and  Dynamic  subsystems  are  designed  using  a modular  concept  which  allow?  new  model 
o be  easily  added  by  the  Advanced  User  of  MUXSIM.  The  Executive  subsystem  orovie'es 
the  interface  between  the  user  and  the  other  three  subsystems;  in  addition,  it  provides 
c aching  features  for  maximum  ease  of  use  ir.  an  interactive  environment.  The  cocch.ing 
: nuru.es  err.  omitted  in  the  Harris  batch  version  of  MUXSiM. 


From  an  operational  or  computer  center  manager's  point  of  view,  MUXSiM 
is  a fair!;  large  software  package  which  requires  substantial  computer  resources  for  storage 
..nd  operation.  Physically,  it  consists  of  about  11,700  Fortran  statements  (9,500  for 
MUXSIM’s  four  subsystems  and  2,200  for  GASP).  It  is  used  in  conjunction  with  10,700 
cards  which  describe  the  signal  flow  list  for  the  A-7D  aii craf; . This  nigral  flow  ‘1st 
comprises  the  primary  workload  for  the  current  version  of  MUXSiM;  it  describes  aoou 
2650  signals  which  characterize  the  information  transfer  requirements  for  a fairly  complex 
aircraft.  This  workload  was  generated  on  DAIS  Design  Study.  Another  signal  flow  i , 
for  MUXSiM,  called  IDAMST  (integrated  Digital  Avionics  for  Medium  STOL  Tran. 

*as  developed  Ly  Harris  as  an  extension  of  this  contract.  The  IDAMST  workload  cm  ain. 
about  7200  signals  and  consists  of  8200  ccrds. 


MUXSIM  is  designed  for  ease  of  use  but,  like  any  other  tool,  it  con  be  em- 
ployed to  best  advantage  by  those  with  appropriate  background  and  training.  It  is  assumed 
that  the  MUXSIM  Basic  User  has  some  knowledge  of  multiplex  system  design;  such  a person 
can  realize  useful  results  from  MUXSIM  with  very  little  training  in  the  operation  of  MUX- 
SIM itself.  However,  for  more  sophisticated  exercises,  the  Advanced  User  requires  some 
specific  training  in  MUXSIM  and  its  components.  For  example,  to  create  new  static  mod- 
els he  needs  some  knowledge  of  Fortran;  and  to  create  new  dynamic  models,  he  must  famil- 
iarize himself  with  details  of  GASP.  In  short,  although  MUXSIM  is  designed  to  be  easy 
to  use,  it  is  not  fully  automatic  - it  requires  a good  humcn  driver.  Furthermore,  although 
MUXSIM  may  be  modified  or  transferred  to  another  host  system  with  relative  ease  (i.e., 
it  is  "portable"),  these  operations  also  require  soms  special  knowledge.  References  I 
and  2 contain  the  information  needed  for  any  advanced  use  or  modification  of  MUXSIM. 

Regarding  the  future,  MUXSIM  has  been  enhanced  by  addition  of  another  signal 
flow  list  (IDAMST,  mentioned  previously).  Harris  believes  that  operational  usage  will  pro- 
vide the  best  possible  source  of  feedback  on  MUXSIM  enhancement  or  modification  require- 
ments. In  addition,  the  Harris  MUXSIM  implementation  and  verification  efforts  to  date  have 
alrecdy  revealed  a number  of  desirable  improvement  or  enhancement  areas.  These  are 
identified  in  the  report. 

In  summary,  this  report  gives  an  overview  of  the  What,  When,  Why,  and 
How  of  a multiplex  system  development  and  analysis  tool  called  MUXSIM.  In  view  of  the 
continuing  importance  of  multiplex  systems  in  aircraft  avionics  systems  design,  there  are  many 
present  opportunities  for  such  use.  Significant  improvements  and  enhancements  to  MUXSIM 
now  appear  to  be  possible,  but  Harris  believes  that  their  specifics  are  best  determined  by 
feedback  from  actual  operational  use.  In  other  words,  Harris  believes  that  future  MUXSIM 
changes  should  be  mostly  evolutionary;  it  is  so  designed  as  to  accommodate  such  changes  with 
minimal  cost. 


In  conclusion,  MUXSIM  has  been  developed  and  implemented  after  o careful 
design  study  by  a team  thoroughly  familiar  with  the  multiplex  system  design  process.  It 
is  a simulation  too!  intended  to  enhance  the  capabilities  of  the  multiplex  system  designer; 
it  is  not,  however,  intended  to  replace  either  him  or  his  other  tools.  MUXSIM  works,  it 
is  easy  to  use,  and  it  is  not  excessively  expensive  to  operate.  Harris  believes  that  MUXSIM 
is  now  ready  for  operational  evaluation.  Such  an  evaluation  should  show  that  it  is  cost- 
effective,  and  that  it  will  lead  to  substantial  development  cost  savings  and  reduced  develop- 
ment cycle  times  for  future  aircraft  multiplex  systems. 

The  remainder  of  this  report  is  organized  into  seven  major  sections,  the 
contents  of  which  are  summarized  below. 

Section  II  (MUXSiM  Purpose)  deals  with  the  motivation  behind  development 

of  the  system. 
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Section  III  (MUXSIM  Description)  is  concerned  with  what  MUXSiM  is. 
Descriptions  are  provided  from  the  functional,  the  logical,  and  the  operational  viewpoints. 

Section  IV  (MUXSIM  Benefits)  is  an  attempt  to  answer  the  question  "How 
valuable  is  MUXSIM?"  In  addition  to  a general  value  assessment,  the  section  contains 
results  of  four  specific  simulation  experiments  which  were  conducted  during  the  course 
of  MUXSIM  verification. 

Section  V (MUXSIM  Use)  discusses  the  general  circumstances  of  MUXSIM 
use;  i.e.,  the  background  requirements  placed  on  the  user,  how  the  interactive  features 
simplify  use,  typical  use  techniques,  etc.  Also  covered  are  typical  use  costs,  cs  reflected 
by  the  computer  resource  requirements  for  the  conduct  of  the  four  simulation  experiments 
mentioned  above.  MUXSIM  use  is  not  coveted  in  great  detail,  because  a comprehensive 
MUXSIM  User's  Manual  exists  which  is  solely  devoted  to  that  purpose. 

Section  V!  (MUXSIM  Modification)  is  concerned  with  how  MUXSiM  may  be 
modified  and/or  moved  from  one  host  system  ro  another.  Again,  this  subject  is  not  treated 
in  great  detail  because  a sepcrare  MUXSIM  System  Modification  Design  Data  Manual 
has  been  created  for  that  purpose. 

Section  VII  (MUXSIM  History)  summarizes  the  development  of  MUXSIM 
from  the  initial  concept,  through  design  and  development,  to  implementation  and  verifi- 
cation. Section  VII  addresses  rhe  question,  "Where  did  MUXSIM  come  from?".  Supple- 
mentary detail  for  the  three  phases  of  the  effort  is  provided  in  Appendixes  A and  3,  while 
an  index  to  all  technical  notes,  interim  reports,  ere.  developed  during  the  course  of  the 
MUXSiM  effort  is  provided  in  Appendix  C and  in  the  Bibliograpny . 

Section  VIII  (MUXSIM  Future)  deals  with  the  question  "Where  is  MUXSIM 
going?"  it  covers  possible  extensions  to  and  improvements  of  MUXSiM,  together  with 
recommendations  on  methodologies  for  MUXSIM  enhancement,  as  well  as  identification 
of  some  specific  areas  where  further  development  now  seems  desirable. 

Finally,  Section  IX  is  a summary  of  the  report,  plus  its  conclusions  and 
recommendations . 


I 


Suction  ii 


MUXS' M PURPOSE 


Ail  simuiot  „-rs  u ed  as  design  tools  basically  cnswer  ' vnat  i"  ' qo 

,'.c  i v< ' ch  a.e  posed  either  indirectly  or  directly.  For  exampie,  a simulation  run 
typical!',  constitutes  part  cr  all  of  a simulcfion  experiment  which  is  perform ea  i*her  rs 
part  cf  a trade-off  s;  .ay  or  as  part  of  a assign  verification  exercise.  In  ‘ne  "ormer  s 
iign  • moy  v \ o know  which  oe  severe’  n » Itiplex  system  e sign  ch« 
the  best  performance  for  a given  information  transfer  v/oncicod.  Here  his  quest  on  is: 
‘Whar  is  P (performance)  for  a specified  X (’design  alternative),  given  W (v  c.  ■ c d p! 
ether  aspects  of  the  working  environment)?"  In  the  latter  case  h:s  question  is  s:m.!or, 
he  may  wish  to  assure  himself  that  the  design  performs  adequately  over  a range  of  wor«- 
(oads.  Then  the  question  becomes:  "What  is  P (performance)  for  a speci'.ed  W (work  . 
given  X (a  design  alternative)? 

The  results  of  several  specific  simulation  experiments  of  the  type  that  can 
easily  be  run  using  MUXSIM  are  given  in  Section  iV  of  this  report,  therefore  <uch  detoi>: 
will  not  be  discussed  here.  Presently,  the  point  to  be  made  is  thot  the  initio!  version  r>; 
MUXSIM  was  deliberately  restricted  in  scope  so  as  ro  easily  and  efficiently  handle 
predefined  classes  of  a multiplex  system  designer's  questions,  but  nor  all  possible 
able  questions  that  he  might  ask.  This  preliminary  scoping  was  a primary  cu  . 

MUXSIM  definition  study,  and  is  the  key  to  MUXSIM's  presen*  cost-eff^ctw  "ess. 
Examples  of  the  questions  to  which  MUXSIM  is  directly  applicable  are: 

0 How  many  remote  terminals  are  required  for  a given  ;nfo- nation  irons' er 
workload? 

« What  is  the  optimum  bus  protocol  for  use  in  a typical  fighter  airc 
interior  multiplex  system? 

® What  is  the  bus  loading  associated  with  the  particular  au>  command  a 
control  scheme? 

e What  is  the  minimum  save  data  bus  speed  for  a given  ir ; ry  t.' rion  tre  • 
workload  and  bus  command  and  control  discipline,  or  how  fast  must  t e 
data  bus  be? 

* What  is  the  impact  on  bus  loading  resulting  from  the  add-on  of  so  . era! 
new  avionics  subsystems  to  the  bus? 

o What  are  the  quantitative  advantages  of  o particular  multiplex  sy.s'em 
redundancy  management  scheme,  given  a certain  EM!  bus  noise  anc 
multiplex  subsystem  failure  environment? 

» What  is  the  impact  on  bus  controller  performance  requirem  its  cf  in- 
creasing information  transfer  workioaa  tor  c fixed  bus  spee*  ? 
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• What  is  the  probability  of  lost  or  erroneous  data  for  a particular  redun- 
dancy design  and  given  noise  and  failure  environments? 

• What  is  the  impact  on  bus  loading  of  a doubling  of  sample  rates  for  a 
certain  set  of  bus  quantities? 

Among  the  questions  for  which  MUXSIM  is  usually  either  not  applicable  or  only  indirectly 
applicable  are: 

• What  is  the  maximum  permissible  length  of  the  bus  for  a given  bus 
technology? 

• What  is  the  bit  error  rate  for  a given  bus  system  design  and  noise  en- 
vironment? 

• What  is  the  point  at  which,  from  a life  cycle  cost  standpoint,  the  multi- 
plex system  becomes  more  cost-effective  than  a hardwired  system? 

To  summarize,  MUXSIM  is  designed  to  be  directly  applicable  to  a set  of 
multiplex  system  designer's  "what  if"?  questions  that  cannot  be  readily  answered  by. 
other  available  means.  The  version  of  MUXSIM  that  has  been  implemented  is  now  di- 
rectly applicable  to  a considerable  number  of  such  questions;  and  because  of  MUXSIM’s 
modular  architecture,  it  is  readily  extensible  to  cover  a still  broader  domain  of  questions. 
The  scoping  issue  is  the  key  to  MUXSIM's  cost-effectiveness.  In  contrast,  tne  lack  of 
suitable  scoping  has  been  the  key  to  failure  of  many  simulators  in  the  past.  Because  it  is 
often  possible  to  simulate  systems  at  any  desired  level  of  detail,  it  is  not  unusuai  for  a 
simulator  designer  to  attempt  to  simulate  "the  universe";  and  if  he  attempts  to  do  so,  the 
resulting  simulator  is  likely  to  be  very  expensive  to  construct,  very  difficult  to  use,  and 
excessively  expensive  to  run.  MUXSIM  was  deliberately  designed  to  avoid  this  common 
problem . 
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Sf.TlON  'll 


MUXSIM  DESCRIPTION 


1.  INTRODUCTION 

in  this  section,  summary  descriptions  of  MUXSIM  are  given  from  *h  ce  poinis 
of  view:  name!'/,  rh?  functional,  the  logical,  and  the  operorioncL  I hese  viewpoints 
nro  intended  to  refie.  rho  interests  of  the  multiplex  system  designer,  the  MU. CS!M  i rr. -o • e - 
reenter,  and  the  MUXSIM  operator,  respectively . The  descriptions  are  only  sjmn.c-.c. 
because,  as  was  noted  in  the  introduction,  details  of  MUXSIM  descriptions  from  variou 
viewpoints  ate  provided  in  the  MUXSIM  User’s  Manuai,  in  the  MUXSIM  System  Mocifi- 
cotron  Design  Data  Manual,  and  in  the  Appendixes  to  this  report 


c , 


FUNCTIONAL  VIEW 


General 


e functional  view  is  MUXSIM  as  seen  by  its  .rtendec  primary  cser, 
who  is  a multiplex  system  designer.  He  is  interested  in  such  questions  as  'When  should  . 
u^e  it?”  and  "How  do  S use  it?";  and  he  sees  it  mainiy  os  an  analysis  too!.  Specif 
it  is  a tool  called  a "discrete  event  software  simulator”;  and  like  mos*  simulate.,  rate  td 
tor  use  in  design  applications,  it  helps  to  provide  cnss.ers  tc  a designer's  wnc;  i1 ' iyo= 
questions.  Through  its  use,  he  is  able  to  get  faster  and  mere  occurate  answers  to  a certain 
set  of  design  questions  than  would  hove  been  possible  without  it.  As  has  been  mentioned 
eariier,  MUXSIM  is  not  intended  to  replace  oil  of  the  designer’-  -ocls;  rather,  it  replaces 
some  and  complements  others.  Although  MUXSIM  fills  ihe  gep  between  manual  analysis 
and  breadboerding  techniques,  it  totally  replaces  neither.  If  wes  r.or  intended  to  be, 
end  is  nor,  a universal  analysis  fool . However,  because  of  its  modular  design  and  tc 
other  rea.ons,  MUXSIM  is  highly  flexible;  iA  can  therefore  be  easily  modifed  and/or 
enhancea  to  perform,  analysis  tasks  which  are  not  directly  performable  with  MUXSIM  a: 
is  presently  implemented. 


A top-ieve!  view  of  MUXSIM  as  seen  by  its  user  is  given  in  ,-igjre  i . » n . s 
figure  is  a revised  or.  rput  of  the  MUXSiM  definition  phase*,  and  shews  mom?  than  was 
actually  scoped  for  i rplementation . However,  that  which  was  implemented  is  compatible 
with  this  figure,  whl’e  that  which  was  net  implemented  continues  to  be  (poter.tiauy) 
desirable;  therefore  the  figure  can  be  regarded  as  Doth  a conceptual  'eve:  descriptic  c 
that  which  MUXSIM  now  is,  and  a blueprint  for  that  which  MUXSIM  miight  become  1 
the  future. 


*See  Reference  5 and  Appendix  A of  this  report 
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/,  q vs-em  designer  wishing  to  use  simulation  as  a-,  analysis  toci  must 
somehow  provide  inputs  whi  h describe  at  least  three  types  of  strr.  ,'lotion  in  part.  Tnese 
are: 


. if.  . ic  ■ describe  the  system  being  simulated,  or  system  models; 

(p.pt.r-;  w'  icS  describe  the  inputs  to  the  simulated  system,  or  model 
woi  k loads; 


inputs  which  describe  the  desired  selection  and  form  Simula. non 
outputs  d simulator  run  modes. 

Vhe  ease  of  u^e  of  a simulator  con  be  measured  by  how  easily  the  designer 


may  specify  such  things  as  those  listed.  In  Figure  2,  these  three  types  are  called  'system 
description  inputs",  "wo  x load  description  inputs",  and  "simulation  control  incurs", 
resp ecfi ve'y . They  may  be  specified  at  many  possible  levels;  four  oarticu'cr  .evels  are 
shov-n  in  tne  figure.  However,  for  the  present  version  of  MUXSIM,  inputs  are  specified 
at  l evel  1.  The  other  incut  levels,  although  usable,  generally  require  significant  manual 
effort . Airo,  there  are  three  defined  categories  of  simulate  outputs  shown  in  the  figure, 
called  " functional",  "operational1',  and  "other".  For  the  present  version  of  MUXSiM, 
most  outputs  are  in  categories  i and  2,  consistent  with  the  simulavor  focus  on  the  sys'e. 
or  "big  picture"  class  of  designer  questions. 


The  interested  reader  will  Find  a full  description  of  Figure  ! n Apper.aix  A, 
therefore  such  detail  need  not  be  repeated  here,  ine  present  implements  Hen  anc 
sta  us  for  the  13  numbered  functional  boxes  of  Figure  1 Is  as  summarized  in  Table  I . 

of  the  13  blocks  identified,  11  hove  been  either  partially  or 
comp*  etc  I y built,  while  two  were  left  for  possible  future  implementation. 


b . System  Users 

At  this  point,  it  is  convenient  to  define  two  types  of  MUXSIM  users, 
rvcly,  the  Basic  User  and  lie  Advanced  Use*-.  MUXSIM  is  designed  to  be  easy  for  fh  - 
former  to  use,  but  he  is  limited  In  what  he  ccn  do  with  it.  MUXSIM  can  be  pur  to  a much 
i oq  jo:  range  cf  uses  by  the  A dvanced  User,  but  he  must  be  quite  familiar  Ith  detail* 
of  MUXSIM  structure  and  other  software  items.  We  next  consider  these  two  ynes  separa 
Basic  User  first. 


(1)  Basic  User 

rhc  Basic  User  normally  selects  a multiplex  system  model  from  a 
, tot  I mod  I Figure  1,  Block  5,  Factor  Library.)  He  also  selects  a 

desired  workload  bom  the  workload  library  and  the  outputs  he  wishes  to  see,  * j rr,e 
s«>ts  t >e  ‘mutator  >to  execu; ion.  In  do...g  the  a Dove,  tie  is  substantia I iy  aiuec.  by  tne 
fbc^utive  subsystem  lich  controls  the  interactions  of  the  other  subsystem:  w 
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Table  1.  MUXSIM  CONCEPTUAL  HOST  IMPLEMENTATION  SYSTEM 

Relevant 


Block  Number 

Block  Name 

Implementation  Status 

MUXSIM  Subsystem 

1 

Operator  Controls 

Implemented 

Executive 

2 

Vehicle  Selection 

Not  Yet  Implemented, 
Need  More  Data 

1 

i 

3 

Avionics  System 
Listing 

Partial ly  Implemented 

Utility 

• 

I 

4 

Prediction  and 
Growth  Modifiers 

Not  Implemented,  Need 
Historical  Data 

5 

Factor  Library 

Partially  Implemented 

Executive  Subsystem, 
Static  Subsystems 

• Models  SA,  SB,  SC, 
SD,  SE,  SF,  SG,  SH 

Dynamic  Subsystem 

• Models  DA,  DB 

6 

Signal  Flow  Listing 

Partially  Implemented 

Utility  Subsystem, 
A-7D  Data  Base 

7 

Workload 

Implemented 

Utility  Subsystem, 
Executive  Subsystem 

8 

Configuration, 
Sequencing  and 
Control 

Implemented 

Executive,  Static 

9 

Redundancy 
Configuration  and 
Error/Failure  Status 

Implemented 

Executive,  Dynamic 

« 

10 

Workload  Library 

Partially  Implemented 

Utility,  Executive 

* r 

11 

Simulation 

Implemented 

Executive,  Utility, 
Static,  Dynamic 

12 

Outputs 

Implemented 

Executive 

i 

. * 

. 4 

» 

13 

Operator 

Presentation 

Implemented 

12 

Executive 

els  ore  available,  w ert 

.npoTi  . eve  vo  be  suppl le-i  .:c.  In  addition.,  the  Basic  User  may  modify  an  existing 
workload  or  deri-o  a new  one,  dett  \ seining  -lie  accomplishment  of  which  will 

. . ch  is  arimarily  ntended  fa  ths  Jt  ic  User), 

i-resent I y ovoibbi.-  T*  1 - U.  r ore  eight  "stciic"  morels,  two  "dynamic"  models, 

.ird  or  . 'work  - • I.  the  "•:iat5c,!  models  ere  shown  SA,  SB  Sri;  the 

1 • - rc  DA  . id  >h  onr  "workiood11  is  the  signal  flow  list  for  ihe  A-7D  aircraft. 

; x dynamic"  were  selected  as  terminology  for  models  because 

rhf  -ormer  rep»v.- 1 r . class  o.  models  for  wh'ch  the  dynamic  mane. , ..  ,it  o . mutates 

terns  that  are  'steady  state"),  while  the  latter  represent  a 
dvno  ■ >f  simulated  time  i - . ; tired.  In  general,  dynamir 

models  deal  with  stochastic  sv  nts  which  occur  at  specific  bet  unpredictable  times,  one. 

■ • squire  sp<.  Jfi;  .ys  c i i s-i savior  in  consequence  of  tneir  occurence. 

(2)  Advonc  e d_l  Jser^ 

Y Advanced  user  of  M.  JXS  V.  has  available  to  him  a ! ! of  the 
facilities  available  to  ie  Basic  User;  in  addition,  he  can  moaify  existing  rncaels,  add 
new  models,  and  o.  . • • . fv  MUXS1M  a;  he  sees  fit.  Because  MUXSIM  is  of  mod- 
ularised dt  - . ;n  . an  a>.  v->ASd,  ; ;se  ecu.  "a,  ■■  are  nor  very  diffi- 

cult to  perform,  dov/eve  , r ••  df  cried  knowledge  of  MUXS1M  implementarion  is  re 
quired  of  the  Advanced  User  if  1 e wishes  to  perform  these  fc»<s.  f •$.  informa  nor  is 
able  in  the  previously  referenced  MUXSIM  System  Modification  Design  Dale  Mcmuai. 

In  addition  to  providrj  .A  ..  sn  f - r;  Advanced  User  of  MUXSIM  the  referenced 
manual,  alio  r'ovides  nfar  or  needed  :o  make  substantial  MuXSiMi  enchancement., 
or  to  move  MUX5IM  from  . present  cst  system  (the  DtC  System-10)  !o  another  i.ost 
system.  Because  such  a trame-  ' not  c.  fr'culf  to  perform,  MUXdlM  is  said  to  be  "portable  . " 


In  summary  , the  functional  view  of  MUXS1M  consists  of  MUXS! M ns  seen  by 
its  primary  user,  who  is  assumed  to  be  a multiplex  system  cosigner.  Such  a person  win 

• typically  use  MUXS'-M  to  answer  "big  picture"  or  systems-ievel  types  of  questions.  The 

► answers  he  seeks  are  normally  whether  or  nor  the  system  being  simu'ei ed  works  at  all,  and 

f it  does  work,  how  well.  The  Basic  User  of  MUXS1M  uses  it  in  unmodifie  i orm,  except 
thar  ire  may  change  workloads;  his  primary  reference  manual  is  tire  MUXSIM  User's  Manual 

; The  Advanced  User  r r MUXSIM  may  modify  ne  sysrem,  citer  osd  rr.cdeis,  add  new'  ores, 

change  outputs,  t ic  , r.  i e sees  fit.  His  primar  ■ refer -rice  monte  is  the  MUXSIM  System 

• Modification  Design  Data  Manual.  He  may  also  require  Fortro  i,  GASP,  anchor  TO 

j -eforence  manuals,  . epending  on  the  particular  change,  or  enhancements  He  wishes  to 

r?  make . 


3. 


LOG i CAL  VIEW 


The  logical  view  of  MUXSIM  is  that  seen  by  the  MUXSIM  implementer.  He 
is  typically  interested  in  such  questions  as  - "How  do  I build  it?",  "How  is  it  built?", 

"How  do  I verify  it?".  Such  an  implementer  sees  mainly  software  structure;  and  his  view 
of  this  structure  may  be  at  high  or  low  levels  depending  on  whether  he  is  mainly  a software 
architect  or  mainly  a coder. 

The  primary  document  which  provides  this  view  of  MUXSIM  is  the  MUXSIM 
System  Modification  Design  Date  Manual.  This  manual  contains,  in  addition  to  flow 
charts  and  program  listings,  the  functional  specifications  that  MUXSIM  realizes. 

From  this  logical  viewpoint,  MUXSIM  consists  of  a hierarchy  of  named 
software  entitles,  as  below: 

• System  - the  whole  of  MUXSIM 

o Subsystem  - I of  4 major  components  of  the  system;  namely,  the 
Executive,  Utility,  Static,  and  Dynamic 

• Program  - 1 of  several  maior  components  of  a subsystem 

• Subprogram  - 1 of  several  major  components  of  a program 

e Subroutine,  or  Module  - 1 of  several  major  components  of  a subprogram 

In  addition  to  these  components,  the  MUXSIM  implementer  sees  internal 
MUXSIM  interfaces  as  well  as  external  interfaces  (e.g.,  interface  between  MUXSIM  and 
its  users,  and  interfaces  between  MUXSIM  and  the  operating  system  of  its  host  computer 
system).  To  simplify  MUXSIM  development  and  verification,  and  to  increase  flexibility, 
modules  have  been  kept  small,  with  interfaces  that  are  as  clean  as  possible.  Also,  to 
keep  MUXSIM  as  small  as  possible  (in  terms  of  number  of  lines  of  source  code),  modules 
are  generalized  and  shared  as  much  as  possible.  To  make  MUXSIM  easy  to  use,  consid- 
erable effort  has  been  spent  on  the  user  interface;  and  to  reduce  MUXSIM  development 
costs,  considerable  use  has  been  made  of  the  DEC  System-10  operating  system  (TOPS-IO). 
Some  of  the  MUXSIM  components  are  reentrant,  while  others  are  not;  this  is  because 
there  was  no  initial  requirement  that  MUXSIM  be  usable  by  more  than  one  user  at  a time. 

4.  OPERATIONAL  VIEW 

The  operational  view  of  MUXSIM  is  that  view  seen  by  the  MUXSIM  operator  or 
by  its  host  computer  center  manager.  His  typical  questions  are:  "How  do  I get  MUXSIM 
running  on  my  system?",  "How  much  of  the  computer  resources  are  tied  up  by  it?  (disk 
space,  core  space,  CPU  time,  etc.)",  "How  should  I charge  for  its  use?",  and  "How 
do  I store  it  on  the  system?". 
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bysicaliy,  MUXSiM  is  totciiy  described  by  aboui  11,700  cards,  as  follows: 


a MUXSIM 

Executive  Subsystem,  1840  cards 
UtiUtv  Subsystem,  2745  cards 
Static  Subsystem,  36d0  cards 
Dynamic  Subsystem,  1245  cards 
o GASP,  2200  cards 

7'ne  A--7D  data  base  which  was  used  in  the  development  of  MUXSIM  is 
10,700  cards. 

for  reasons  of  economy,  it  may  be  best  to  store  MUXSiM  on  magnetic  tape. 

In  this  form,  a 1200-foot  reel  of  80(H>pi  magnetic  tape  is  sufficient  for  the  job;  if  stored 
in  punched  cara  form,  about  six  boxes  of  cards  are  needed.  After  compilation  and  link  or, 
the  DEC  System-10,  MUXSIM  consists  of  about  510  blocks  of  object  code  which  will 
normally  be  keor  resident  on  the  DEC  System-10  disk.  The  disk  requirements  are: 

* MUXSiM 

Executive  Subsystem,  66  blocks 
Utility  Subsystem,  143  blocks 
Static  Subsystem,  177  blocks 
Dynamic  Subsystem,  124  blocks 
a GASP,  133  blocks 

» A-7D  Data  Base,  1699  blocks 

When  operated  on  DEC  System-lC,  Mb-XSIM  is  normaiiy  segmented,  end 
requires  a partition  of  30k  36-bit  words  for  execution.  CPU  time  requirements  for  typ  ci 
.se  of  the  MUXSIM1  are  difficult  to  estimate  because  a typical  use  of  MUXSIM  is  difficult 
to  define;  however,  as  a guideline,  the  CPU  time  requirements  for  typica,  simulation 
experiments  (discussed  subsequently  in  Section  IV)  are  shown  :n  Table  !:. 
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Table  II.  SIMULATION  EXPERIMENT  RESOURCE  REQUIREMENTS 


Experiment 


1 

2 

3 

4 


Experiment  Name  CPU  Time  Required  fMIn) 

Bus  Loading  vs.  Bus  Command  and  20.7 

Control  Schemes 

Bus  Loading  vs.  Bus  Speed  10.4 

Controller  Loading  vs.  Bus  Loading  10-4 


Impact  of  Command  and  Control 
Uncertainties  on  the  Periodicity  of  the 
Fundamental  Update  Interval  starts 


From  the  date  in  Table  II,  the  typical  costs  of  a simulation  experiment  may 
be  estimated.  For  example,  if  we  assume  a cost  of  $8/min  for  DEC ■ System-1C > time,  t rhen 
the  computer  costs  of  the  four  experiments  in  question  are  about  $165,  583,  583,  end 
553  respectively.  These  cost  estimates  are  made  for  illustrative  purposes  omy  and 
show  that  typical  MUXS1M  run  costs  are  probably  not  excess, ve  Actual  costsde spend 
on  the  particular  computer  system  accounting  practices  employed  ror  the  MUXSIM  host 
system.  They  canof  course  vary  widely.  More  details  of  interest  in  an  oparahona  view  of 
MUXSIM  may  be  found  in  the  MUXSIM  System  Modification  Design  Data  Manual  (re,.  2). 

As  was  mentioned  earlier,  a batch  version  of  MUXSIM  now  exists  which  runs 
on  the  Harris  Datacraft  6024/5.  This  is  c moderate-size  minicomputer  system  which 
includes  32k  24-bir  words  of  core  and  a disk.  The  existence  of  this  batch  version  shows 
rhat  MUXSIM  can  be  tailored  to  run  on  a fairly  small  computer  system;  however,  since 
this  version  of  MUXSIM  is  simply  a byproduct  of  the  MUXSIM  development P">cess  °nd 
not  a contractual  end  item,  it  is  not  presently  described  in  available  MUXSlM  documen 

tat  ion . 
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SECT1C.n1  IV 


muxs ;m  benefits 


1.  INTRODUCTION 

The  inain  purpose  of  this  section  is  to  attempt  to  answer  the  question, 
"Of  what  vcL-e  is  MUXSIM?",  both  briefly  and  substantively.  This  is  done  oy 
first  summarizing  toe  general  benefits,  anc!  then  describing  four  specific  simuia- 
i i o : . experiments  that  have  been  run  using  MUXSIM,  together  with  tneir  results. 

2.  GENERAL  BENEFITS 

MUXSIM  is  mainly  intended  as  a multiplex  system  designer's  analysis 
tool.  Specific  examples  of  how  MUXSIMi  can  be  helpful  are  provided  in  the  fol- 
lowing paragraphs. 

In  adcirion  to  its  analysis  role,  MUXSiM  can  also  be  helpful  in 
production  and  software  stages  of  a multiplex  system  development.  This  is  be- 
cause several  of  its  outputs  are  in  such  a form  as  to  be  directly  usable  as  the 
multiplex  system  design  moves  toward  these  later  stages.  For  the  most  part  these 
outputs  are  helpful  because  without  MUXSIM  they  would  have  to  be  produced 
by  tedious  and  error-prone  manual  means,  whereas  MUXSiM  generates  them  auto- 
matically. The  remote  terminal  wiring  list  is  an  example  of  one  such  output; 
multiplex  system  bit,  word,  and  message  maps  are  olher  examples  , in  »he  former 
ccse,  if  is  a necessary  step  in  the  production  process  to  assure  that  each  signal 
which  is  an  output  from  one  terminal  is  an  input  to  another,  and  vice  versa. 

While  this  is  a conceptually  simple  signal  accounting  task,  it  is  very  tedious  tc 
perform  manually.  In  the  latter  case,  where  the  multiplex  system  is  of  the  tsrre- 
division-multiplex  (TDM)  type,  it  is  necessary  to  know  which  signals  are  assigned 
,o  each  field  and  which  words  are  in  each  message  in  order  to  write  or  modi 
multiplex  system  software.  This,  too,  is  a conceptually  simp'e  task,  but  tedious 
lo  oe Torn i manual. y.  (Note:  in  the  A-7D  signal  now  ist,  there  are  265'j  sic.nais, 
and  this  v moderate-size  signal  flow  list  as  a'rcrafv  multiplex  systems  go.  Some 
1 orge  aircraft  have  a signal  flow  list  of  i3,0C0  signals.,’ 

3.  SAMPLE  SIMULATION  EXPERIMENTS 

For  present  purposes,  a MUXSIM  simulation  experiment  means  “a 
planned  sequence  of  MUXSIM  runs  intended  to  provide  answers  to  one  or  more 
significant  questions  posed  by  a multiplex  system  designer."  The  ease  end 
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accuracy  with  which  MUXSIM  can  be  applied  in  obtaining  answers  to  typical  sig- 
nificant questions  is  a true  measure  of  MUXSIM's  effectiveness. 


As  contractually  defined,  the  overall  MUXSIM  design,  development 
and  verification  effort  did  not  provide  funding  or  time  for  a significant  MUXSIM 
operational  effectiveness  evaluation.  (This  work  is  under  way  as  part  of  contract 
F33615-76-C-1099.)  However,  as  part  of  the  MUXSIM  verification  efforts,  several 
sample  simulation  experiments  were  performed  which  illustrate  typical  results  which 
can  be  easily  attained  by  the  MUXSIM  Basic  User.  Four  such  experiments,  together 
with  their  results,  are  briefly  summarized  below.  Three  of  them  use  static  models, 
while  the  fourth  uses  one  of  the  dynamic  models  provided. 

a.  Experiment  1 - Bus  Loading  Versus  Bus  Command  and  Control 
Schemes. 

In  this  experiment,  it  was  assumed  that  the  multiplex  system 
designer  wishes  to  know  which  is  the  best  bus  command  and  control  scheme  for 
a given  bus  workload.  He  also  wishes  t-  know  how  much  better  one  scheme  is 
than  another.  For  example,  if  a simple  scheme  is  nearly  as  good  as  a more 
complex  one,  it  may  be  preferable  to  use  the  simple  one  because  it  may  be 
considerably  less  expensive  to  implement. 

The  present  MUXSIM  implementation  consists  of  eight  static 
models  which  represent  eight  different  bus  command  and  control  schemes.  This 
implementation  covers  a wide  variety  of  configurations  applicable  to  TDM  systems, 
ranging  from  completely  centralized  (terminal-to-central-to-terminal)  to  com- 
pletely distributed  (direct  terminal-to-terminal),  and  includes  a number  of  hybrid 
combinations  of  both.  Figure  2 indicates  the  results  of  an  experiment  run  using 
the  A-7D  data  base,  which  is  being  used  to  verify  MUXSIM. 

b.  Experiment  2 - Bus  Loading  Versus  Bus  Speed. 

This  experiment  assumed  that  the  multiplex  system  designer 
wishes  to  explore  details  of  suspected  bus  saturation  effects.  These  effects  take 
w place  ' 'he  vicinity  of,  or  close  to,  TOO  percent  bus  loading.  The  presence  of 

saturat  implies  that  for  practical  purposes  a certain  percent  of  the  apparent 
bus  capacities  are  unusable  for  the  given  bus  scheduling  algorithm.  To  investigate 
these  saturation  effects,  bus  speed  is  systematically  varied  while  the  bus  work- 
load and  command  end  control  schemes  are  held  constant.  (This  is  analogous  to 
* expanding  the  workload.) 

Tne  final  results  for  the  saturation  experiment,  which  used  a 
binary  matrix  sched.jler,  show  that  several  fundamental  update  intervals  within 
the  given  major  frame  become  saturated  at  92.9  percent  overall  bus  loading  for 


the  particular  implementation  tested. 
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STATIC  MUX  MODELS 

Model  Name 

Information  Transfer  Discipline 

SA 

T/T  Transfer 

SB 

T /C/T  Transfer  (bit  shuffling) 

SC 

Digital  TA,  Discrete  T/C/l 

SD 

Hybrid  Transfer 

SE 

T/T  Transfer  with  SOU  Broadcast 

Sr 

T/C/'T  Transfer  with  BOU  Broadcast 

SG 

Hybrid  Transfur  with  30 U Broadcast 

SH 

T/C/T  Transler  tword  shuffling) 

Figure  2.  Bus  Loading  Versus  Bus  Command  and  Control  Schemes 


c.  Experiment  3 - Controller  Loading  Versus  Bus  Loading. 

In  this  experiment  it  was  assumed  that  the  multiplex  system  de- 
signer wishes  to  explore  the  impact  of  high  bus  loading  on  controller  loading.  He 
suspects  that  os  bus  loading  increases,  the  controller  may  have  to  work  harder  in 
order  to  implement  the  given  fixed  command  and  control  algorithm.  As  in  the 
preceding  experiment,  bus  loading  is  increased  by  decreasing  bus  speed  while 
maintaining  constant  workload  and  bus  command  and  control  scheme.  The  con- 
troller loading  is  measured,  for  this  experiment,  by  counting  the  number  of  dif- 
ferent message  group  sequences  that  must  be  handled  by  the  controller  as  the 
bus  load  is  varied.  The  results  of  this  experiment  are  given  in  Figure  3. 

d.  Experiment  4 - impact  of  Command  end  Control  Uncertainties 

on  the  Periodicity  of  the  Fundamental  Update  Interval  Starts. 

This  experiment  involved  the  use  of  a GASP-based  dynamic 
model.  The  resuits  are  illustrated  by  a GASP  histogram  plot.  For  this  experi- 
ment, a bus  load  which  consisted  primarily  of  the  periodic  messages  plus  back- 
ground demand  messages,  and  a command  ar.d  control  scheme  which  consisted 
of  addressing  a terminal  and  waiting  for  a terminal  to  respond,  were  assumed. 

The  delays  in  terminal  response  could  conceivably  cause  the  start  of  an  update 
interval  to  be  delayed  until  a response  is  received  from  a terminal.  The 
response  time  variations  are  attributed  to  several  factors,  including  clock  varia- 
tion and  problem-caused  variations  such  as  failures  of  the  response  mechanism, 
whereas  the  bus  controller  has  to  await  the  timing  out  of  a watchdog  timer, 
which  disables  the  terminal  from  responding,  before  the  bus  controller  is 
free  to  proceed.  This  delay  can  cause  the  scheduled  start  time  for  the  next 
message  to  be  delayed,  thereby  impacting  the  start  of  the  next  update  cycle 
or  fundamental  update  interval.  Should  this  happen,  it  delays  the  start  of 
every  message  in  that  interval  by  that  amount. 

The  histogram  in  Figure  4 shows  statistics  of  the  update  inter- 
val start  time  jitter  (expressed  in  fractions  of  the  update  interval  duration) 
measured  while  running  this  particular  experiment. 

4.  CONCLUSIONS 

in  summary,  it  v/as  stated  that  MUXSIM  in  its  present  form  can 
provide  immediate  and  significant  benefits  to  both  the  multiplex  system  designer 
and  to  associated  personnel,  who  may  be  production  engineers  or  software  de- 
velopers. Also,  four  specific  simulation  experiments  were  described  together 
with  results  to  illustrate  some  particular  simulation  experiments  that  can  be 
easily  performed  by  a MUXS’M  Basic  User.  Although  these  experiments  are 
thought  to  be  typical  of  those  likely  to  be  performed  by  a multiplex  system 
designer,  no  extensive  analyses  were  made  of  the  results,  and  no  hard  con- 
clusions regarding  multiplex  systems  being  simulated  could  be  drawn.  The 
phenomena  explored  included  bus  loading  and  saturation  effects,  and  the 
impact  of  redundancy  management  schemes. 
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SECTION  V 
MUXSIM  USE 


1.  INTRODUCTION 

This  section  is  primarily  addressed  fo  the  two  questions,  "How  is  MUXSIM 
used?  >d  ‘What  re  MUXSIM  use  costs?",  for  the  typical  Basic  User.  The  Drst  au  . 
tion  was  briefly  treated  in  Section  ili(MUXSIM  Description);  here  i is  cove  . a in  so.r  - 
what  more  derail.  Th  second  question  Is  portia’ly  answered  by  -etezence  to  compo 
resource  cost;  associate':  with  the  conduct  of  the  four  simulation  experiments  bisc^s-s 
."ectio.i  IV,  where  the  question  was  treated  briefly. 

2.  USER  TYPES 

As  was  noted  earlier,  there  are  two  main  types  of  MJXSIM  user,  ne  has  a 
Lher  and  the  Advanced  User.  The  former  uses  MUXSIM  essentially  as  is  and  relies  pri- 
marily on  the  MUXSIM  User's  Manual,  together  with  the  built-in  coaching  features  of 
the  MUXSIM  Executive,,  in  order  to  conduct  his  simulation  exercises.  The  latter  requires 
a more  detailed  k no  v I edge  of  MUXSIM  software.  Therefore,  he  generally  requires  in- 
formation found  in  the  MUXSIM  System  Modification  Design  Data  Manual.  He  may  c‘ 
require  knowledge  of  Fortran,  GASP,  and/or  7OPS-10,  depending  on  the  tyoe  of 
SIM  use  he  has  in  mind.  Boih  types  of  user  are  assumed  to  be  familiar  v>h  .-re 
of  multiplex  system  design.  This  section  summarizes  the  needs  and  procedures  cl  . r.e 
MUXSIM  Basic  User,  while  Section  V|  summarizes  needs  and  procedures  of  tne  Advc 
User. 

3.  TYP  CAL  MUXSIM  USE 

fo  discuss  how  MUXSIM  is  typically  used,  it  is  first  necessary  to  define 
typical  MUXSIM  use.  For  presenr  purposes,  we  assume  that  a typlcai  M JXS.M  use 
the  condi  of  a simulation  experiment  such  as  described  by  the  flow  chart  c Figu*  ^ 
Given  this  tiow  chart,  the  Basic  User  may  be  definec  more  precisely  as  one  who  norma.! 
uses  ail  of  the  blocks  shown  except  Biock  6. 

4.  BASIC  MUXSIM  USE 

The  starting  point  for  any  employment  of  MUXSiM,  whether  by  the  Be-  c 
User  or  Advanced  User,  is  the  determination  of  the  multiplex  sysrem  desigr.  question 
which  an  answer  is  desired.  Depending  on  what  this  question  's,  MUXSIM  may  c-  may 
not  be  applicable.  (Here,  "appiiccbie"  means  that  MUXSIM  can  be  either  directly  used 
without  modification,  or  that  the  required  MUXSIM  modificat  ons  are  oomoctible  with 
me  user’s  time  and  budget  constraints).  If  MUXSiM  is  nor  applicable,  then  some  c . 
analysis  technique  must  be  selected  and  used  in  order  to  answer  the  question.  Blocks  , 

2 and  3 of  the  flow  chart  are  concerned  with  these  matters,  and  at  present  c:  tne  ? <. 
involved  are  conducted  manually.  The  user  must  be  sufficiently  cognizcnt  cf  the  n.. 
and  structure  at  MUXSIM  to  carry  out  the  steps  satisfactorily. 
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START 


DETERMINE  DESIGN  QUESTION 
TO  BE  ANSWERED 


WHAT  .S  THE  DESIGN 
PROBLEM? 


IS  MUXSIM 
APPLICABLE? 


USE  SOME  OTHER  ANALYSIS  ( 
TECHNIQUES 


PLAN  SIMULATION  EXPERIMENT 


HOW  MAY  IT  BE  ANSWERED  THROUGH 
USE  OF  MUXSIM? 

ARE  MUXSIM  MODIFICATIONS  NEEDED? 

WHAT  INPUTS,  OUTPUTS  AND  MODELS 
ARE  NEEDED? 


WILL  MODIFICATIONS  Be 
NEEDED,  OR  WILL  MUXSIM 
SUFFICE  AS  IS? 


BASIC  OR 
ADVANCED 
USE? 


MAKE  NEEDED 
MODIFICATIONS 
OR  ADDITIONS 


MODIFY  OR  ADD  MODELS? 
CHANGE  MUXSIM  STRUCTURE ? 


SELECT/PREPARE  WORKLOAD(S) 


MODIFY  EXISTING  WORKLOADS 
ADD  NEW  WORKLOADS 


SELECT  AND  PREPARE  MODELS 


CHOOSE  STATIC  OR  DYNAMIC 
MODELS  FOR  USE,  AND  SET  UP 
THEIR  PARAMETERS 


RIATE  suitable  GRAPHS, 
CHARTS,  ETC. 

WHAT  DOES  IT  MEAN? 

IS  IT  CREDIBLE? 


HAS  PROPER  DATA  BEEN 
COLLECTED? 

IS  THERE  ENOUGH  OF  IT? 


j MAKE  SIMULATION  RUNS,  GENERATE 
DESfREO  OUTPUT  DATA 


DISPLAY,  ANALYZE  AND  INTERPRET 


OUTPUT  DATA 


DRAW  CONCLUSIONS 


WHAT  IS  THE  ANSWER  TO 
THE  QUESTION? 


Figure  5 

Typical  MUXSIM  Use  - Conduct  of  a Simulation  Experiment 
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Block  4 involves  the  planning  o~  the  simulation  experiments,  r or  the  most 
per",  'he  detailed  steps  required  are  simi'ar  iO  those  needed  .r>  the  planning  of  any  sci- 
entific sxperimeni , whether  if  be  simulation,  physical,  or  other.  Typicci  considerations 
include  preparation  c 'nouts,  provision  re  outputs,  length  o time  required  for  the  ex- 
periment statisficc!  validity,  errors  introduced  by  instruments,  etc.  These  subjects  will 
nor  be  covered  hi  dura.'  here  - suffice  if  to  say  that,  for  this  typical  use,  the  MUXSIM 
jser  \ sxoected  io  . we  : basic  understanding  of  the.  scientific  me  hod  arid  an  ability  to 
mop  i-  a good  experim  •ntal  practice  info  the  MUXSIM  context.  Like  the  other  blocx' 
discussed  above,  Blocl  u is  mainly  implemented  by  manual  means. 

Sleek ; 7 8,  9,  and  10  in  the  simulation  experiment  bow  chart  are  those 
w!  ich  are  mainly  re  mtzed  by  MUXS'- M.  If  is  here  that  the  four  major  MUXSIM  sub- 
systems (Utility,  Static.,  Dynamic,  and  Executive)  come  info  clay.  Briefly,  the  Utility 
subsystem  provides  a library  of  preprepared  workloads  and  a set  of  aidsfor  workload  develop- 
me-f  and  modification;  the  Static  subsystem  provides  a library  of  preprepared  "steady- 
state  multiplex  system  models;  the  Dynamic  subsystem  provides  preprepared  srochastic 
models;  and  the  Executive  subsystem  controls  operations  of  the  other  subsystems  while  oiso 
providing  powerful  coaching  features  for  the  user  if  he  selects  this  option.  It  is  largely 
this  collection  of  MUXSIM  features  which  substantiates  the  claim  that,  for  the  Basic  User, 
MUXSIM  is,  indeed,  "easy  to  use."  Those  who  have  used  any  modern  computer  time- 
sharing system  will  readily  understand  the  general  nature  of  these  MUXSIM  user-oriented 
features.  Their  details  and  specifics  are  given  in  the  MUXSIAA  User’s  Manual  and  ere 
repeated  in  this  Final  Report. 

Block  10  of  the  flew  chart  is  largely  accomplished  by  manual  means.  It  s at 
this  point  in  a simulation  experiment  that  the  Basic  User  decides  whether  or  not  he  has 
sufficient  data,  whether  the  data  he  Iras  seems  credible,  etc.  For  example,  i'  he  is  using 
the  output  data  to  plot  a curve  (of  the  results  of  the  simulation  experiments  discussed 
earlier),  he  may  find  if  necessary  to  obtain  additional  data  points  to  better  display  the 
shape  of  the  curve,  especially  for  its  critical  regions.  Finally,  block  il  is  where  the 
experimenter  attempts  to  puil  together  all  simulation  results  in  order  to  bray  c conclusior 
and  (hopefully)  to  either  answer  or  shed  light  on  his  original  question.  This,  too,  : 
largely  a manual  operation  at  present. 

5.  COSTS  OF  MUXSIM  USE 


Although  simulation  can  produce  interesting  and  usef  rrr  s,  it  ' not  un- 
common to  find  inappropriate  uses  of  simulators  wherein  trivial  res,  !'s  are  generated  a 
substantial  computer  cost..,  or  where  useful  results  are  produced  s-u  at  very  hign  comp  h- 
costs.  An  example  of  the  latter  could  be  the  estimation  of  mu  tip! ex  bus  bir  error  rc 
✓ la  simulation;  in  this  case,  the  desired  estimates  might  be  obtained  after  n ch  comivCm 
number  crunching,  while  estimates  of  comparable  accuracy  could  have  Dee  obtained  by 
o.Ser  means  (e.g.,  by  manual  analysis  o>  by  breodboa,  .*  er>...  ..os!  ' c;  usiderabl 

lower  costs. 
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In  the  specification  and  design  of  M'JXSIM,  a strong  effort  was  made  to 
avoid  its  use  in  areas  of  predictable  low  cost-effectiveness.  It  is  hoped  that,  for  the 
most  part,  this  effort  has  been  successful;  however,  the  overall  cost-effectiveness  of 
MUXSIM  cannot  be  rigorously  demonstrated  without  a significant  operational  evaluation 
effort.  This  has  not  yet  been  completed.  Therefore,  the  best  that  con  be  done  at  this 
point  is  to  show  some  indications  of  MUXSIM  cost-effectiveness.  That  is  the  purpose  of 
this  section. 

The  method  used  to  obtain  these  indications  was  to  consider  some  typical 
simulation  experiments  carried  out  using  MUXSIM,  and  to  estimate  the  computer  costs 
associated  with  running  each  experiment.  These  costs  may  be  estimated  by  measuring 
the  computer  resources  used  for  each  experiment,  and  by  assigning  costs  for  these  re- 
sources using  costing  schemes  consistent  with  industry  practice;  i.e.,  by  using  the  "going 
rate"  for  the  various  computer  resources  used.  The  first  task  is  not  difficult,  since  most 
operating  systems  for  large  computer  systems  like  the  DEC  System-10  produce  computer 
resource  utilization  accounting  data  as  a by-product  of  normal  operations. 

Applying  this  costing  methodology  to  the  four  simulation  experiments  de- 
scribed earlier,  results  are  as  shown  in  Table  II  (Section  III).  From  this  data  is  may  be 
inferred  that  a "typical"  MUXSIM  simulation  experiment  has  a direct  computer  resource 
cost  of  about  $50- $200  based  on  experiment  run  time  and  CPU  cost  of  $8/min.  Of 
course,  though,  this  figure  will  vary  widely  with  computer  resource  accounting  practices 
from  one  host  computer  system  ro  another,  and  so  it  is  useful  as  a "ball  park"  estimate  only. 

6.  SUMMARY  AND  CONCLUSIONS 


This  section  has  been  concerned  with  the  two  questions  "How  is  MUXSiM 
used?"  and  "What  are  MUXSIM  use  costs?",  for  the  typical  Basic  User.  In  order  to  get 
at  the  answer  to  these  questions,  a typical  MUXSIM  use  was  defined  by  a flow  chart 
which  covers  the  case  of  a routine  simulation  experiment.  The  flow  chart  serves  to  show 
the  simulation  experiment  as  a whole;  it  also  shows  specifically  how  and  where  MUXSIM 
aids  in  the  conduct  of  the  experiment.  Certain  steps  must  be  accomplished  manually. 
Examination  of  some  of  these  steps  serves  to  show  what  requirements  are  placeo  on  the 
user  in  order  for  him  to  use  MUXSIM  effectively. 


Costs  of  "typical"  simulation  experiments  are  estimated  by  conventional 
means,  and  found  ro  be  $50-$200  for  the  simulation  experiments  1 through  4 described 
in  Section  IV.  These  estimates  are  intended  to  be  considered  as  "ball  park"  figures 
only,  since  the  costs  will  vary  with  different  simulation  experiments  and  with  different 
computer  resource  accounting  methods.  The  cost-effectiveness  of  MUXSIM  is  not, 
therefore,  rigorously  demonstrated  by  this  analysis  effort;  rather,  it  is  shown  that  costs 
of  certain  simulation  experiments  felt  to  be  typical  are  not  excessive. 


In  conclusion,  results  of  the  analysis  efforts  reported  here  indicate  that 
MUXSIM  should  be  both  easy  to  use  and  cost-effective  for  the  basic  User.  However, 
firm  conclusions  on  this  matter  must  await  c more  complete  MUXSIM  operational  evalu- 
ation. 
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SECTION  V! 


MUXSIM  MODIFICATION 

The  Advanced  User  may  wish  to  modify  MUXSIM  by  alteration  or  addition  of 
Static  and  Dynamic  models  and  in  many  other  possible  ways.  In  addition,  others  may 
wish  to  modify  MUXSIM  for  various  reasons;  for  example,  it  may  be  desired  to  move  MUX- 
SIM to  a new  host  system,  to  enhance  MUXSIM  with  features  conceptually  defined  but  not 
yet  implemented,  to  add  more  coaching  features  to  the  Executive,  to  decrease  MUXSIM 
run  times  by  tuning  operations,  etc.  For  those  wishing  to  modify  MUXSIM  for  any  reason, 
the  MUXSiM  System  Modification  Design  Dora  Manual  is  the  primary  source  of  informa- 
tion. 

A MUXSIM  modification  mcy  be  very  easy  or  quite  difficult,  depending  on 
the  type  desired.  Factors  tending  to  make  the  modification  easier  include  the  following: 

w MUXSIM  is  implemented  almost  entirely  in  Fortran  IV  and  GASP. 

« MUXSIM  is  implemented  in  modular  fashion,  with  relatively  clean 
intermodule  interfaces. 

s MUXSiM  is  well  documented  in  the  System  Modification  Design 
Data  Manual . 

However,  certain  modifications,  such  as  those  needed  to  move  MUXSIM  to 
another  host  computer  system,  can  be  fairly  complex  since  portions  of  MUXSIM  (mainly 
the  "user-convenience'1  software)  are  operating  system-dependent.  This  is  because,  to 
reduce  MUXSiM  development  costs,  certain  MUXSIM  functions  are  implemented  using 
TOPS-IO  (the  DEC  System-10  operating  system  in  use  at  AFAL)  instead  of  making  MUX- 
SiM completely  seif-contained.  Thus,  when  MUXSIM  is  moved  to  a new  operating  sys- 
tem, these  functions  must  be  re-implemented  either  as  part  of  MUXSIM  itself  or  through 
the  use  of  suitable  ^unctions  of  the  new  operating  system. 

Whatever  rhe  MUXSiM  modification  desired,  the  information  necessary  to 
perform  it  is  contained  in  the  MUXSIM  System  Modification  Design  Data  Manual,  which 
includes  sections  o MUXSIM  architecture,  components,  modification,  and  installation. 

It  also  contains  the  MUXSIM  functional  specification. 

Recommended  Procedures  for  certain  specific  types  of  modificarions  are 
given  explicitly,  while  for  other  types  the  modifier  must  plan  his  own  procedures.  The 
reader  interested  ir  details  concerning  this  subject  is  referred  to  the  System  Modification 
Design  Data  Manuel  for  further  information. 
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SECTION  Vi! 


MUXSIM  HISTORY 


1 . OVERVIEW 

MUXSIM  l.  . is  covered  in  detail  in  Appendices  A and  E of  this  report 
' lcc,  O.u;  ly,  the  pur.  ,e  o , is  section  is  to  give  only  a brief  mrnary  of  that  ' :storv.  C.crc 
t'  f MU  XS*M  design  •_  id  ' xopmcnt  e 'fort  has  oeen  a three-phase,  31  -morfh  eOo. : , The  tr 
phi,--  - ' v discuss*  . •.  , the  iO>iow;.og  subsections. 

MUXSIM  PHA,;t  I - DEFINITION 

Phase  I was  a definition  study  which  addressed  the  desigr  alternatives  for  a 
multiplex  system  simulator  oopat  e of  permitting  the  evaluation  of  do  to  transfer  concepts 
ana  techniques.  Ir  culminated  in  a two-voiume  Interim  Technical  Report  (Ref.  5)  which 
describes  the  elements  of  air  vehicle  multip.ex  systems  and  the  concepts  required  to  simu- 
iofe  them.  The  referenced  report  contains  three  mair.  sections,  embodying  coverage  of 
multiplex  systems  analysis  'It, viator  inputs/outputs  and  variables,  and  simulator  construc- 
tion methods. 

The  most  significant  question  arising  during  Phase  ! involved  the  deer  .V. 
tion  of  simulator  outputs.  In  the  study  it  was  concluded  thcr,  for  maximum  Air  Force 
benefits,  MUXSIM  should  be  designed  so  as  to  be  applicable  at  the  earliest  possible  time 
in  the  multiplex  system  design  cycle.  MUXSIM  outputs  were  selected  so  as  to  be  com- 
patible with  that  design  objective.  Other  Phase  I recommendations  based  on  tne  study 
results  were  as  fallows: 

« Certain  aspects  of  multiplex  system  design  Gre  best  handled  on  an 
analytic  bars.  These  include  bus-  elated  matters  such  as  bi,  error 
rate,  impedance  matching  ana  transmission  line  pros! err. .,  TDM  vs 
F DM  trade-off  studies,  etc.  Although  computer  p-ograms  can  be  val- 
uable in  support  of  such  studies,  it  was  recommenced  that  such  pro- 
grams not  be  made  port  or  MUXSIM  initially  in  order  to  avoid  the 
problems  or  excessive  simulator  run  times  end  excessive  simulator  size 
and  development  costs. 

a To  reduce  A/.UXSIM  initial  development  costs  and  '’cciiltcte  later 

changes,  the  highest  level  implementation  language  feasible  should  be 
used.  Specifically,  GASP  and/or  Fortran  should  be  used  as  primary 
implementation  languages  for  this  simulator. 

« lhe  test-bed  mode  of  MUXSIM  operation,  with  its  real-tine  implica- 
tions, should  he  considered  as  separate  from  and  independent  of  othci 
modes  of  operation. 
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• The  non-test  bed  portion  of  MUXSIM.  should  be  considered  mainly  as 
software,  with  littie  or  no  special  hardware  required. 

• To  ensure  MUXSIM  feasibility  and  relevance,  MUXSIM  specifications 
should  be  developed  in  parallel  with  a small-scale  simulation  exercise 
to  model  and  simulate  those  areas  of  the  B-l  EMUX  System  which  have 
in  hindsight  caused  the  most  design  problem, s,  and  wherein  early  simula- 
tion could  apparently  have  done  the  most  to  alleviate  those  problems. 

An  example  or  such  a problem  area  is  thct  of  redundancy  management. 
MUXSIM  specifications  should  be  developed  in  part  by  generalization 

of  the  small-scale  simulation  mode,  developed  for  the  B-l  EMUX  analysis. 

• Tne  MUXSIM  project  shouia  be  continued  through  specification  and  pro- 
totype development  phases,  because  there  is  strong  evidence  that  MUX- 
SiM can  be  a very  powerful  and  cost-effective  design  tool. 

More  details  regarding  specific  Phase  I study  methodology,  results,  and  con- 
clusions may  be  found  in  Appendix  A and  in  Reference  5. 

3.  MUXSIM  PHASE  il  DESIGN 

Phase  II  was  a follow-on  study  leading  to  the  functional  design  and  specifica- 
tion of  MUXSIM.  Results,  conclusions,  and  recommendations  of  that  study  are  contained 
in  the  four-volume  Second  Interim  Technicc!  Report  (Ref.  6).  A condensed  and  revised 
version  of  that  report  is  included  in  Appendix  A to  this  report. 

The  main  objective  of  the  MUXSIM  Phase  II  study  was  the  specification  of 
MUXSIM  design,  together  with  a discussion  of  the  design  features  and  rationale.  The  re- 
sulting design  was  consistent  with  the  results  and  recommendations  of  the  Phase  I study 
without  any  major  differences,  except  that  DAIS  was  used  as  the  object  of  a smail-scaie 
probe-coding  exercise  instead  of  B-i  EMUX. 

A major  MUXSIM  design  goal  was  cost-effectiveness.  This  was  pursued,  in 
general,  by  attempting  to  keep  MUXSiM  development  and  use  costs  low  while  maximiz- 
ing use  benefits.  The  attempt  to  maximize  benefits  involved  primarily  a continuing  em- 
phasis on  MUXSIM  focus  and  scope,  realism,  ease  of  use,  and  flexibility.  Substantially, 
this  meant: 

1. 


2. 

3. 


Focus  on  those  practical  and  important  multiplex  system  design  questions 
which  must  be  answered  early  In  the  multiplex  system  design  cycle. 

Focus  on  design  questions  which  are  best  answered  by  simulation. 

Emphasis  on  real  multiplex  system  workloads. 
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. Emph«'-  i ur.  1 i'.c  •/!  make  MUXS.  V 3 too.  vis  id1  is  conven- 

ient on  easy  to  use. 

5.  emphasis  on  ‘to  ...  ..  which  pic  e MUXS  1M  eosy  io  moony  and/or  expand 
(i.e.,  f lex ib : > y features). 

Th  sin  |!e  rrost  imp  - .tar  • xr  ' 'n.  . - zing  MUXSIM  benefits  was  the  heavy  nvolve- 
'■  MUX i M de<  :ed  - ex  systei  ...  si  . were  very 

fair  i!iar  • ti  ..hat  des'jn  uestions  must  be  answered  earliest,  which  are  the  rr.cst  impor- 
ts t,  and  which  ca  1.  v answer;  J easily  by  other  available-  ;co's  and  technic, ues. 

Th.s  atiempt  to  ~>.;r! seize  MUXSiMt  cevelopment  o-.c  use  casts  involved  a 
numbt  of  approaches,  inducing  : he  following; 

e ire  development  costs  down  by  use  of  high-level  imple- 

mentor h-  language  (e.g.,  cy  the  use  of  Fortran). 

« Keeping  software  developme  : s down  by  avoiding  ‘re-invention  of 
the  wheel"  (e.g.,  by  use  of  GASP  for  development  of  dynamic  simula- 
tion models  . 

» Keep! no  y hware  development  costs  down  (and  flexibility  up)  by  use  of 
modular  software. 

• Keep  1 g saltwort  deveiopmenl  costs  down  by  maximum  use  of  functions 
provided  by  the  host  system's  operating  system . 

a Keepir  • de  /c  ionment  and  use  cost:,  down  by  making  MUXSIM  itself  as 
small  us  pass:  !e  initially  (this  i elates  directly  to  the  scope  issue 
mentioned  earlier). 

v Keeping  use  costs  down  by  making  MUXSIM  interact  '<e  v.-r.-h  extensive 
coaching  features  (this  curs  down  significantly  on  user  training  costs  end 
on  user  time,  but  not  necessarily  on  comparer  time  components  of  use 
cost). 

The  single  most  important  factor  in  arriving  of  a MUXSIM  do.  gn  for  rr.:  - mum  evelopnent 
and  use  costs  was  the  heavy  involvement  o software  designers  woo  we.  experienced  ;n 
fne  design  and  use  of  interactive  simulation  packages. 

As  part  of  the  Phase  II  effort,  c MUXSIM  system  specifier  ion  was  .repared 
using  guidelines  set  forth  in  MIL-STD-490  and  MIL-STD-483.  Additional  de  ch  was  sup- 
plied from  a number  of  c‘het  documents,  some  of  which  wer  be.h  mo  pi  ob;-coding 
exercises  which  were  done  c-  part  of  this  study  phase.  Details  of  this  data  are  n Appendix 
A of  this  report,  and  in  Ref.  6. 
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4. 


MUXSIM  PHASE  II!  - IMPLEMENTATION  AND  VERIFICATION 


Phase  III  was  the  actual  implementation  and  verification  phase  of  MUXSIM.  It 
has  resulted  in  an  operational  version  of  MUXSIM,  together  with  all  required  supporting 
documentation.  The  latter  includes  this  Report  as  well  as  the  MUXSIM  User's  Manual  and 
the  MUXSIM  System  Modification  Design  Data  Manual.  A GASP  IV  Manual  (ref.  4)  is 
also  needed.  (This  GASP  IV  manual  is  avaiiaole  from  almost  any  good  technical  bookstore.) 
Since  a detailed  report  on  MUXSIM  Phase  III  is  included  as  Appendix  B to  this  Report,  only 
a summary  and  highlights  of  if  are  given  here. 

For  the  most  part,  MUXSIM  was  implemented  and  ver  ried  according  to  the 
specifications  and  plans  set  forth  as  the  outputs  of  Phase  II  of  the  Study.  The  two  main 
changes  to  the  original  specifications  were  the  following: 

1 . The  MUXSIM  host  system  was  redesignated  to  the  DEC 
System-10  instead  of  tne  originally  planned  PDP- 11/45. 

2.  A number  of  MUXSIM  output  formats  were  changed  so  as 
to  be  more  user-oriented  tnan  those  originally  picnned. 

The  first-mentioned  change  required  some  MUXSIM  redesign  because  parts 
of  MUXSIM  (mainly  the  "convenience"  software)  ore  operating  system-dependent.  The 
second-mentioned  change  entailed  mainly  the  addition  of  dictionaries  to  allow  MUXSIM 
outputs  to  be  more  in  text  form  and  less  in  terms  of  numbers. 

As  now  implemented,  MUXSIM  comprises  four  major  subsystems:  the  Utility, 
the  Static,  the  Dynamic,  and  the  Executive.  These  subsystems  are  in  turn  divided  into 
programs,  then  subprograms,  and  finally  into  subroutines  or  modules.  Most  coae  is 
written  in  Fortran,  but  some  is  in  GASP,  and  the  Executive  makes  some  use  of  the  TOPS- 10 
control  statements.  For  development  purposes,  code  testing  was  done  at  the  module  level; 
but  for  MUXSIM  verification  purposes,  testing  was  done  at  a program  level.  As  was  noted 
earlier,  four  small  simulation  experiments  were  conducted  as  part  of  the  MUXSIM  verifi- 
cation effort.  Ail  necessary  details  regarding  MUXSIM  as  implemented  may  oe  found  in 
the  MUXSIM  System  Modification  Design  Data  Manual,  while  design  rationale  will  be 
found  in  Appendixes  A and  B to  this  report  as  well  as  in  References  5 and  6. 


SECTION  VII! 
MUX  SI  V FUTURE 


Thtb  sect  . concerned  mainly  with  the  quesdon  "V'here  should  'or  might' 
from  ;n€r  ' " h treating  this  Question,  sorni  H t is  opinions  on  tne  matter  ere 
presented,  roge‘her  \ , . i listing  of  some  areas  where  MUXS1M  imp'ovements  or  enhance- 
mer.ts  miahf  nov'  b*--  ■ ^-raoie.  Th.  lent:-.  are  dor  ved  from  r.orr:  experien*. es  in  >he  im- 

plementation -or  if'-notion,  and  limited  operational  use  or  MUXSIM. 

To  re vier  the  situation  brie?  MUXSIM  is  a multiplexer  system  des. goer's 
tool  which  has  bet  n designed,  implemented,  ana  verified;  but  it  is  a too,  which  nas  not 
>ct  been  extensively  tested  through  actual  use.  Therefore,  it  is  darns'  opinion  thcr  the 
next  iog.cai  step  is  the  operational  evaluation  of  MUXS  I M,  and  that  such  an  evaluation  will 
provide  the  best  possible  source  of  inputs  regarding  needed  improvement-  and  enhancement:, 
if  any. 


Harris  believes  strongly  the:  in  the  case  of  a tool  such  as  MUXSIM, 
evolutionary  impress ements  based  solidly  on  its  use  history  are  the  best  lend  It  is 
noteworthy  that  a number  of  sue  sessful  modern  software  simulation  packages  have 
been  developed  by  his  route;  SIMSCRIP7,  GASP,  and  GPSS  are  cases  in  point. 

Although  real  use  generally  is  Me  best  source  of  information  on  MUXSIM 
development  enhancements  Mot  may  be  needed,  there  are  some  areas  where  tne  neea 
for  further  development  is  already  quite  clear.  For  example,  a larger  workload  library 
is  evidently  desirable.  Enhancements  like  rhis  ore  require  no  changes  to  MUXSIM 
structure,  and  Immediately  extenc  he  rouge  or  useta!  esuits  tnot  can  oe  derived 
from  MUXSIM. 

Other  specific  possibilities  fc  MUXSIM  development,  which  emergea 
as  Harris  rook  MUXSIM  through  implementation  and  verification  stages,  include 
fhe  following: 

s.  Use  of  a graphics  terminal  to  aid  in  remote  terminal  assignments. 

«■  Better  integrator  of  vAUXSIM  dynamic  models  with  real  world  data 

bases  (workloads). 

» Further  growrh  of  dynamic  models;  e.g.,  to  allow  direct  investigation 
of  multiplex  processor  end  bus  control:*  r loading  phenomena. 


d3 


Further  development  of  static  models  to  allow  study  of  multiple  bus 
and  multi-line  bus  configurations. 


ever 

real 


Many  other  possibilities  could  be  mentioned  in  addition  to  the  above.  How- 
, consistent  with  the  view  that  further  development  needs  are  best  established  through 
use  experience,  Harris  recommends  implementation  of  them  on  an  "as  need"  basis. 
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SECTION  IX 


SUMMARY,  CONCLUSIONS  AND  RECOMMENDATIONS 


This  Report  has  covered  the  design,  development,  implementation,  and 
verification  of  a multiplex  system  simulator  called  MUXSIM.  MUXSIM  is  intended  as  a 
multiplex  system  designer's  analysis  tool,  to  be  used  primarily  in  the  early  stages  of  a 
multiplex  system  development  cycle.  As  an  analysis  iool,  it  was  intended  to  be  easy  to 
use,  flexible,  cr.d  productive  of  meaningful  and  credible  results.  Above  all,  it  was  in- 
tended to  be  cost-effective. 

Following  the  introduction,  this  Report  has  included  sections  covering  MUX- 
SIM purpose,  description,  benefits,  use,  modification,  history,  and  its  future,  in  all 
cases,  the  coverage  hos  beer,  in  summary  fashion  with  supporting  details  left  either  for  the 
Appendixes  or  for  two  other  study-generated  documents,  namely,  the  MUXSIM  User's 
Manual  and  the  MUXSIM  System  Modification  Design  Data  Manual. 

The  main  overoll  conclusions  are  that  MUXSIM  was  built  per  spec,  its  correct 
functional  operation  has  been  verified,  and  it  is  thought  to  be  cost-effective.  It  is  obvi- 
ously neither  a perfect  tool  nor  as  complete  as  it  might  be,  but  it  is  designed  to  be  flex- 
ible so  as  to  aiiow  for  easy  modification  ano/or  growth. 

The  best  recommendation  that  Harris  makes  at  this  time  is  that  further 
operational  evaluation  of  MUXSIM  be  conducted;  i.e.,  that  it  be  put  to  the  test  in  a 
real  multiplex  system  design  context,  hopefully,  such  a test  will  reveal  that  MUXSIM 
is  truly  useful  and  beneficial.  Also,  such  a test  is  viewed  as  the  best  possible  source  of 
inputs  for  further  MUXSIM  development  needs. 
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APPENDIX  A 

MUXSIM  DEFINITION  AND  DESIGN 
PHASE  I AND  PHASE  II  REPORT 
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INTRODUCTION 

The  purpose  of  this  appendix  is  io  provide  supporting  detail  regaiding  pro- 
cedures, resuits,  and  rationale  related  to  Me  definition  and  design  phases  of  MUXSIM 
development.  Most  of  the  data  contained  herein  was  obtained  by  the  editing  and 
reorganization  of  data  contained  in  the  Pnase  i and  Phase  !l  Interim  Reports  (references 
5 and  6).  The  interested  reader  can  find  additions:  information  on  these  subjects  .n 
those  two  reports.  The  areas  primarily  supported  by  details  in  this  appendix  ore  MUXSIM 
Description  and  MUXSIM  History. 

The  remainder  of  this  appendix  is  divided  into  five  sections.  Section  li 
covers  the  overall  MUXSIM  development  plan,  including  its  relation  to  specific  state- 
ment of  work  tasks.  Section  ill  covers  Phase  i (MUXSIM  Definition),  and  includes  details 
on  the  what  and  why  of  MUXSIM  description  from  a functional  or  user's  viewpoint.  Sec- 
tion IV  covers  Phase  II  (MUXSIM  Design),  and  includes  details  on  the  what  and  why  of 
MUXSIM  description  from  c logical  or  impiementer’s  viewpoint.  Both  Sections  II  and  IV 
contain  historical  information  as  appropriate,  mainly  concerning  how  the  particular  de- 
scription in  question  was  obtained,  final!'/,  Section  V provides  a summary  and  conclu- 
sions for  the  MUXSIM  Definition  end  Design  phases. 
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SECTION  II 

MUXSIM  DEVELOPMENT  PLAN 


Tc  rui  t':‘s  appendix  in  perspective,  the  overall  MUXSIM  development  plan 
is  shown  i bubble  chart  torm  in  Figure  A-l . As  has  been  noted  previously,  this  oppen- 
dix  < ontcir.,  details  of  the  what,  why,  and  how  of  Phases  I and  II  only.  Appendix  B 
jive.,  a simhar  treatment  of  Phase  III,  while  Phase  IV  hcs  not  yet  been  accomplished.  In 
add iv ion  to  identify! no  tLe  phases  and  their  sequence.  Figure  A-l  shows  the  principal 
outputs  o',  each  Phase. 

A Statement  of  Work  (SOW)  was  used  by  Harris  as  a guide  in  carrying  out 
the  ■tevelopmen*'  pfan.  Altogether,  eleven  SOW  tasks  were  defined  and  executed  in 
tht  course  of  MUXSIM  development.  These  tasks  are  identified  and  their  relations  to 
the  A^UXSIM  phases  are  shown  by  Table  A-l  and  Figure  A-2. 

Details  o;  the  what,  why,  and  how  of  the  MUXSiM  definition  and  design 
phases  are  given  in  the  next  two  sections. 
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MUXSIM  Development  Plan 
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Simplified  Development  Flow  Chart 
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SECTION  III 


PHASE  I - MUXSIM  DEFINITION 

1.  INTRODUCTION 

A summary  view  of  the  four  major  task  groups  which  were  performed  in  the 
definition  phase  is  shown  in  bubble  chart  form  in  Figure  A-3.  The  various  bubbles  ore 
annotated  to  give  some  Idee  of  the  associated  work  details  involved.  A statement  of  the 
general  goo!  of  the  overall  development  effort  is  also  shown  in  this  figure,  together  with 
a major  criterion  applicable  to  that  goal. 

As  may  be  seen  from  the  above,  both  the  goal  and  its  major  criterion  are 
quits  general.  This  fact  accounts  for  the  major  problem  in  Phase  I,  which  was  to  define 
the  problem.  Many  possible  simulation  tools  could  be  defined  which  satisfy  the  general 
goal,  and  a fairly  large  subset  of  these  could  be  cost-effective.  The  MUXSIM  definition 
pease  can  be  characterized  as  a complex  multi-stage  screening  process,  the  main  result 
of  which  was  the  scoping  of  MUXSIM.  Details  of  the  program  and  its  results  are  given 
in  the  following  sections.  Each  of  the  task  groups  shown  in  Figure  A-3  is  covered  in  a 
separate  section. 

2.  TASK  GROUP  1 - FORMALIZE  MUX  DESIGN  PROCESS 

If  a good  multiplex  system  designer's  handbook  existed,  it  would  have  been 
unnecessary  to  perform  this  task  group;  but  since  one  did  not  exist,  its  equivalent  hod  to 
be  created.  The  results  of  the  pseudo-handbook  development  effort  are  contained  in  fuii 
in  Volume  II  of  the  first  Interim  Report  (ref.  5). 

First  Interim  Report  - Volume  !i  is  a comprehensive,  1 i8-page  document 
which  includes  a complete  catalog  of  the  elements  of  multiplex  systems,  a general  de- 
scription of  FDM  concepts,  a description  of  TDM  techniques,  and  another  catclog  of 
alternative  command  and  control  implementations.  Although  it  was  created  mainly  to 
provide  the  background  information  necessary  for  simulator  definition  efforts,  it  can  also 
be  used  on  a stand-alone  basis  to  provide  insight  into  information-transfer  techniques.  In 
fact,  the  document  as  it  now  exists  could  be  used  as  a starting  point  for  the  multiplex  sys- 
tem designer's  handbook  mentioned  earlier. 

To  give  an  idea  of  the  details  covered  in  this  document,  its  Table  of  Contends 
is  g:ven  here  as  Figure  A-4.  As  may  be  seen,  there  are  three  main  substantive  sections, 
covering  multiplex  system  considerations,  structures,  and  command  and  control  techniques, 
respectively.  The  first  of  these  includes  a catalog  of  multiplex  system  considerations,  a 
condensed  version  of  which  is  given  here  as  Figure  A-5.  The  catalog  is  given  in  outline 
form  only;  no  atterr.pt  was  made  to  fill  in  the  details. 

The  bus  structures  section  covers  the  two  most  commonly  used  multiplexing 
techniques,  namely  Frequency  Division  Multiplex  (FDM)  and  Time  Division  Multip'ex 
(TDM).  These  techniques  are  discussed  in  a tutorial  sense  to  provide  the  reader  with  on 
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unders  ending  of  the  problems  which  each  of  tnem  overcomes  or  creates.  Uscge  of  the: 
two  techniques  is  generally  governed  by  the  following  rationale: 

» TDM  terminals  may  all  be  of  identiccl  design,  which  is  a definite  plus 
for  commonality.  However,  if  one  user  requires  a much  higher  data 
ra*e  then  cil  the  others,  then  a special  FDM  channel  may  be  desirable 
(o.g.,  o 10-Mbps  channel  among  a group  of  10-kbps  channels  con- 
streins  n|!  channels  to  a 10-Mbps  receive  rate,  even  though  they  all 
do  nor  require  it) . 

a terminals  work  well  at  baseband,  where  the  transmission  iine  losses 

ore  lowest.  However,  equalizorion  and  amplification  are  more  easily 
achieved  in  FDM  (carrier)  systems;  therefore,  these  systems  are  generally 
preferred  for  long  transmission  paths  and  very  high  data  rates. 

Finally,  the  command  and  control  section  provides  o diagramatic  summary  of 
the  fundamental  command  and  control  relationships  applicable  to  information-transfer 
systems.  Although  some  of  the  schemes  described  lend  themselves  more  to  one  multiplex- 
ing scheme  than  another,  no  attempt  is  made  to  catalog  on  that  basis.  A special  graphi- 
cal notation  was  developed  to  facilitate  description  of  a wide  variety  of  command  and 
control  relationship., 

in  summary,  the  efforts  of  Task  Group  1 led  to  the  preparation  o'  a siz 
document  in  which  comprehensive  and  detailed  information  regarding  multiplex  sys?e 
design  is  presented  n weli  structured  form  it  clearly  illustrates  the  range  of  o.ecs  m 
vh.’ch  design  decisions  must  be  mode,  and  provides  guidelines  on  the  basis  or  which  freae- 
offs  can  be  made.  However,  it  does  not  provide  a formal  mode!  of  the  rrultiolex  system 
design  proce  . which  indicates,  for  example,  the  sequence  in  which  vor'ous  design  deci- 
sions should  be  made.  Such  a model  could  serve  as  the  basis  for  a rrue  "cook  book'' 
approach  to  multiplex  system  design;  but  it  appears  that,  at  present,  development  of  this 
type  of  model  is  beyond  the  state-of-the  art. 

3.  TASK  GROUP  2 - SIMULATION  TECHNOLOGY  STUDY 

In  the  case  of  Task  Group  1,  the  equivalent  of  a multiplex  system  designer's 
handbook  was  needed  as  a starting  point  for  the  MUXSIM  development.  Au.o  required  is 
the  equivalent  of  a simulator  designer's  handbook;  and  then,  given  these  two  items,  the 
definition  of  MUXSIM  could  emerge  as  a result  of  various  screenings  anc  tradeoff  studies. 

However,  whereas  the  equivalent  of  a multiplex  system  designer's  hano'  ook 
had  to  be  created  (because  an  existing  one  could  not  be  found),  the  equivalent  of  a 
simulator  designer's  handbook  does  already  exist  amidst  the  voluminous  iiterature  on  sim- 
ulation (books,  papers,  'angjages,  etc,).  Therefore,  Tark  Group  2 v as  easier  to  perform 
than  task  Group  1,  since  it  consisted  mainly  of  a screening  process  on  a relatively  we.! 
defined  existing  base  of  simulation  technology. 


Considering  simulation  as  a whole,  it  is  immediately  evident  thct  the  range 
of  simulator  types  is  very  large.  For  example,  simulators  can  broadly  be  classified  either 
by  intended  usage  or  by  technology,  as  shown  in  Figure  A-6. 

It  was  assumed  during  the  MUXSIM  definition  phase  that  the  MUXSIM  host 
system  was  to  be  a DEC  PDP-11  multiprocessor  system  as  shown  in  Figure  A -7,  with  pos- 
sible relationships  to  multiplex  system  physical  components  as  shown  in  Figure  A-8.  It 
was  further  assumed  that  the  desired  enc  product  was  a simulator  which  was  a cost-effec- 
tive multiplex  system  designer's  tool,  as  indicated  in  Figure  A-3.  Therefore,  given  these 
assumptions,  it  was  tentatively  conduced  that  the  desired  MUXSIM  would  probably  be  of 
type  U2-T1  (see  Figure  A-6).  This  conclusion  was  helpful  in  restricting  the  scope  of  de- 
tailed simulation  technology  investigations. 

The  principal  rationale  associated  with  host-system-related  MUXSIM  scoping 
is  as  follows.  First,  the  host  system  is  generally  viewed  as  a powerful  minicomputer  sys- 
tem which  provides  medium-scale  computing  power  at  a low  price;  i.e.,  at  a price  suf- 
ficiently low  that  dedicated  use  of  the  system  for  an  application  such  as  MUXSiM  is 
economically  viable.  Second,  the  small  word  size  of  the  host  system  processors,  together 
with  their  small  memories  and  lower  speeds  relative  to  existing  larger  systems,  means 
that  the  use  of  very  large  models  and  powerful  simulation  languages  such  as  GPSS  and 
SIMSCRIPT  may  be  undesirable.  Also,  simulation  experiments  which  entail  very  signifi- 
cant amounts  of  complex  number-crunching  are  best  avoided  on  such  a host  system. 

Fianlly,  the  architecture  of  the  host  system  is  such  that  "foreign"  devices  can  be  attached 
with  relative  ease;  this  is  mainly  because  of  the  Unibus  feature  of  the  system. 

In  short,  the  knowledge  that  MUXSIM  had  to  fit  on  a minicomputer  system 
was  used  in  the  definition  phase  to  restrict  the  range  of  alternative  simulator  types  to  be 
considered  in  detail  for  MUXSIM.  Subsequently,  in  the  implementation  phase,  the 
MUXSIM  host  system  was  redesignated  to  be  the  DEC  System-10,  which  is  a large-scaie 
computer  system.  It  is  noteworthy  that  MUXSIM  as  defined  to  be  suitable  for  minicom- 
puter system  implementation  is  also  suitable  for  large  system  implementation;  however, 
the  converse  wouldn't  necessarily  be  true.  The  main  impact  of  the  original  host  system 
assumption  was  to  prevent  the  definition  of  MUXSIM  as  a very  large-scale  simulator. 

With  toe  above  in  mind,  the  range  of  relevant  simulation  technologies  for 
immediate  study  was  narrowed  to  non-real-time  digital  simulation  of  the  continuous  or 
discrete  event  types,  and  in  forms  suitable  for  implementation  on  a minicomputer  system. 
Continuous  simulation  is  best  suited  for  describing  dynamic  systems  which  are  generally 
characterized  by  differential  equations,  while  discrete  event  simulation  is  best  tor  model- 
ing systems  which  ere  characterized  by  a set  of  discrete  states.  In  the  latter  case,  the 
simulation  represen's  system  behavior  by  moving  the  system  from  state  to  state  in  accord- 
ance with  well-defined  operating  rules,  and  system  state  changes  depend  on  the  occur- 
rence of  discrete  events;  hence  the  name. 

For  recsons  stated  above,  it  was  determined  that  MUXSIM  should  probably  be 
a digital  simulator  useful  as  a design  tool  for  the  multiplex  system  designer,  and  suitable 
for  implementation  on  a minicomputer  system.  Further  focus  was  required  beyond  this  in 
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!r  tended  Usage' 

« ui  - Personnel  training  (e.g..  Link  trainers  for  pilot 

training,  space  flight  simulators 
for  astronaut  training) 

* U2  - "What  if"  question  answering  (e.g.,  models  for 

answering  questions 
related  to  optimal 
economic  policy 
decisions,  models 
for  answering  questions 
related  to  optimal 
system  design) 


Simulator  Technology 

T1  — Digital  Simulators 

si  T2  - Analog  Simulators 

« T3  - Hybrid  Simulators  (part  digital,  part  analog) 


Figure  A-6.  Simulator  Classifications 
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Figure  A -7.  Typical  Test  Bed  interface  - Single  Multiplex  System  Unit 
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orc’e ' tc  resfricJ-  me  ronc.e  of  simulation  fechnoloc  es  to  be  consioered  in  detcii;  cad  in 
part;  or  'be  question  of  the  relation  of  simulator  time  fc  rec:  time  had  to  be  considerc 
In  •;  , (.yard,  it  was  determined  that  MUXS IM  m-ght  weli  na\  e a real-time  mode,  which 
oc. iH  be  j -fu!  in  exercising  multiplex  system  components  for  excmple.  However,  it  wcs 
also  determined  that  this  mod'.  , which  was  turmec  the  "test  bed"  mode,  shou'd  be  defined 
separately  Horn  the  simulator  or  non-real  time  mode,  because  in  the  latter  the  relation 
between  rea1  and  simulated  time  is  of  no  great  consequence.  Also,  it  was  decided  to  con- 
sider ^imt'lntion  technology  for  the  non-real  time  mode  in  detail  first. 

In  summary  of  the  foregoing,  in  consequence  of  a logical  scree  ng  proces  it 
w c.  decided  to  focus  vitial  detailed  simulation  technology  studies  n the  fob  owing  ere-:: 

* Non-rea;  rime 

o Discrete-event 

a Suitable  for  minicomputer  implementation 

This  having  been  decided,  the  technology  study  focused  initially  on  languages 
suitable  for  discrete  event  simulation.  This  study  was  conducted  using  three  different  ap- 
proaches, namely:  (11  an  evaluation  matrix  comparison  of  discrete  event  simulation  lan- 
guages; (2),  a benchmark  comparison  of  same;  arid  (3),  literature  surveys  anc  consulta- 
tions with  external  simulation  experts  on  thet  subject. 

Resuits  of  the  evaluation  matrix  comparison  are  shown  inTables  A-il  jo)  cn.t  -v  il  t; 
Two  tables  are  required  to  cover  two  different  host  computer  systems  (the  DEC  PDP-11  and 
the  DEC  System-10).  The  evaluations  rr.ctrix  is  a convenient  way  to  make  a systematic 
comparison  of  languages  while  considering  a number  of  features,  and  to  develop  a ranking 
of  these  languages.  However,  the  approach  has  its  weaknesses,  and  in  this  application  it 
is  main’y  useful  for  screening  purposes.  Results  of  this  exercise  indicate  the  tentetive  con- 
clusion that  Fortran  and  GASP  are  the  top  two  choices,  whether  the  pior.rea  host  system  i 
the  DEC  fyst-em-10  or  the  PDP-11 . However,  the  ranking  of  other  alternative  simu'ation 
languages  is  host  sys  em  dependent  (e.g.  APL  is  ranked  8^  for  the  PDP-11,  bjt  4th  ror  ‘he 
DEC  System-  10). 

in  further  evaluation  efforts,  a benchmark  approach  was  used  to  compare 
Fortran  and  GPSS  in  development  of  a discrete-event-type  model  of  a simple  messege 
hondiing  system.  Results  of  this  exercise  are  shown  in  Table  A-iil.  Only  two  languages 
were  compared  using  the  benchmark  approach  because  of  the  high  cost  of  using  the  ap- 
oroach  fi.e.,  models  must  be  developed,  debugged  and  run  in  each  language  being  con- 
sidered). From  this  exercise  it  was  concluded  that,  for  models  well-suited  ‘or  the  GFSS, 
the  use  of  GPSS  resu  is  in  substantial  reduction  of  programming  effort  and  a much  smaller 
source  program,  but  t entails  the  use  of  much  greater  computer  resources  for  program 
'’•'-•c'ltion . At  the  time  'his  exercise  was  done,  it  was  still  assumed  thaf  the  MUXS' /V'  '■  nv 
computer  system  was  to  be  the  PDP-11;  and  this  exercise  indicated  that  GPSS  was  not  a 
good  simulation  long  -age  for  use  with  the  PDP-1 1 . 
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Table  A- 1 1 (b).  MUXSIM  IMPLEMENTATION  LANGUAGE  EVALUATION 

MATRIX  (DEC  SYSTEM-  1C) 


Table  A—  1 1 • 


FORTRAN  VS.  GPSS  FOR  MESSAGE-HANDLING  SYSTEM  BENCHMARK 


FORTRAN 

GPSS 

1 . Program  Name 

MHS  1 

MHS  3 

2.  Programming  Effo-t  (Man-Days) 

2 

1 

3.  Debugging  Effort  (Man-Days) 

1 

1 

! 4.  Size  of  Source  Program 

(No.  of  Lines) 

1 

330 

00 

CN 

j 5.  Computer  Resource  Units  (CRU) 
for  computation  and  execution 

3 

24 

Finally,  the  literature  survey/expert  consultation  approach  toward  simulation 
language  evaluation  produced  several  published  simulation  language  inventories  and  com- 
parisons, and  revealed  a number  of  interesting  details.  The  main  result  of  the  effort  was 
to  strengthen  the  impression  that  neither  GPSS  nor  SIMSCRIPT  was  a good  choice  of  im- 
plementation language  for  MUXSIM,  given  that  the  PDP-11  was  to  be  its  host  system; 
but  that  a Fortran-based  discrete  event  simulation  language  called  GASP  was  in  existence, 
well  documented,  well-supported  by  an  independent  software  supplier,  and  well-suited  for 
implementation  in  a minicomputer  system.  In  a crude  estimate  of  simulation  language 
"power",  GASP  was  found  to  occupy  a position  somewhere  between  GPSS  and  SIMSCRIPT 
(the  latter  being  one  of  the  most  powerful  discrete  event  simulation  languages  available). 

In  addition  to  discrete  event  simulation  languages,  several  mature  and  successful  simula- 
tion packages  such  as  SCERT  (System  and  Computer  Evaluation  and  Review  Technique) 
were  examined  in  some  detail  as  part  of  the  literature  survey/expert  consultation  approach, 
but  none  were  found  to  be  directly  applicable  to  MUXSIM. 

in  summary,  the  efforts  of  Task  Group  2 entailed  a broad  survey  of  the  entire  field 
of  simulation  technology  with  particular  emohasis  on  discrete  event  simulation  languages 
that  were  both  mature  and  widely  used.  From  this  effort  it  was  tentatively  concluded  ,-hat 
MUXSiM  should  be  implemented  in  Fortran  and/or  GASP,  and  should  incorporate  some  of 
the  good  features  found  in  mature  and  successful  simulation  packages  such  as  SCERT,  Areas 
of  simulation  technology  such  as  real-time  simulation  techniques,  analog  and  hybrid  simu- 
lation, and  continuous  simulation  languages  were  not  examined  in  detail  pending  demon- 
stration cf  the  need  for  such  investigations.  In  hindsight,  it  is  noteworthy  that  portions  cf 
MUXSIM  have  been  implemented  in  a recent  version  of  GAS  called  GASP  IV,  which  has 
both  discrete  event  and  continuous  simulation  capabilities.  However,  the  latter  have  not 
yet  been  used  in  models  implemented  to  date. 
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4. 


TASk  GROUP  3 - IDENTIFY  SIGNIFICANT  MUX  DESIGN  QUEST.ONS 


Th*»  purpose  of  this  ask  group  wcs  to  idertify  those  significant  multiplex  system 
-resign  questions  which  are  be  ' answered  by  simulation.  Ir  genera  , a design  question  is 
regarded  a?  sign’fican  Oe  cos' -effeci  'veness  of  the  resultant  multiplex  system  is 
trorgly  affecied  by  it:  answer:  end  the  question  is  best  answered  by  simulation  if  its 
answer  cannot  or  at  . cr  jt  S 'ter  by  some  other  means  available  to  the  multiplex  system 
dedr  r sr. 

■ , ide*  ‘fiocni  :n  was  made  mainly  by  o judgmental  process  based  cn  expe'ience 

vita  multiplex  :ys*.cr  fesign  end  sirnulc.  ion  technology  generally  , ..nd  on  the  results  of 
To«!<  Groups  ’ c-b  2,  specifically.  The  process  is  explicitly  displayed  as  a three-phase 
screening  proce  - T i -•  A-9.  A major  assumption  leading  to  the  results  cr  this  effort 
was  bar,  to  ensure  ma,  .mum  benefits  to  the  Air  Force  from  MUXSIM  ■ ;se,  MJXSIM  should 
be  appi.cabe  at  tn_-  ec  . test  possible  rime  in  the  multiplex  system  design  cycle.  Ration- 
ale tor  this  assumption  is  that  early  MUXSIM  applications  have  tne  greatest  leverage  and 
the  ea  t costs.  !i  is  e . imulation  can  be  done  at  u!mc  cry  stage  of  the  design 
cy>  le,  and  in  fact  a hardware  prototype  can  be  viewed  as  a special  case  of  a detailed 
design  simulation,  ft  wev-r,  the  later  n the  design  cycle  that  simulation  is  used,  the 
greater  the  cost  of  simulation  model  development  and  the  greater  the  cost  of  design 
changes  indicated  bv  simu  ■ -it  ion  results,  .f  design  errors  are  found  too  late  in  a design 
cycle,  a major  desigt  change  may  be  impractical  for  cost  and  schedule  reasons,  end  fhu- 
a "band-aid"  type  fix  may  be  necessary. 

Because  of  this  assumption,  the  locus  of  MUXSIM  was  narrowed  sc  os  to  mcke  t 
app'icable  mainly  to  those  significant  d 'ion  questions  which  must  • e an  wered  earliest. 
Thece  are  the  "big  piefu  e"  or  "system:  ype  questions,  : >e  answers  to  which  determine 

the  basic  multiplex  ystem  architecture.  Examples  are: 

s What  is  l e required  bus  speed? 

a What  is  the  bit  error  rate  on  the  bus? 

« What  is  the  optimal  bus  command  and  control  scheme? 

® How  meny  times  per  second  should  a given  bus  signal  be  sampled? 

o How  many  terminals  wii!  be  needed? 

a What  is  the  maximum  acceptable  per  unit  cost  for  the  multiplex  system? 

a Should  >us  control  be  centralized  or  distributed? 

• Who:  is  the  required  redundancy,  and  how  should  ii  Le  managed  (what  i: 
the  required  multiplex  system  MTBF)? 

c Whaf  is  he  impcct  of  varying  multiplex  system  MTBF  on  life  cycle  costs  o a 
fighter  aircraft? 
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Identification  of  Primary  Target  Questions  for 


j Whot  h i probable  reliability  of  a candidate  multiplex  system 
architecture? 

a What  is  the  probable  cost  o;  implementing  a particular  mu.tipiex 

system  design? 

* Y,hat  , iie  -'lex  Ality  cf  a particular  multiplex  system  architecture 
"!y  cun  new  signals  be  added,,  etc.)? 

4 $t  id  7DM  or  FDM  be  employed ? 

Questr.  like  these  comprise  List  1 in  Figure  A-9. 

Although  t^e  above  questions  are  all  significant  and  os’- ed  early,  not  all  re 
b cf  answered  by  '.imu'at’on  (and  specifically  by  simulation  on  c minicomputer  system). 

For  example,  several  areas  of  multiplex  system  design  are  besr  b.cndiea  on  cn  analytic 
basis.  They  include  bus-related  matters  such  as  bi‘-  error  rc'-e,  imoedanc?  matching  and 
transmission  line  problems,  TDM  vs  FDM  tradeoff  srudies,  etc.  A general  rule  used  in 
screening  questions  was  that,  if  a cost-effective  alrernative  means  existed  for  answering 
a given  design  question  adequately,  then  that  question  should  not  be  considered  a prim- 
target  for  MUXS1M.  After  this  second  screening,  'he  questions  rna.  remain  are  those  o: 
List  2 in  Figure  A-?.  Typical  examples  are: 

1.  Whai  is  the  optima!  bus  command  end  control  scheme? 

2.  What  is  the  bus  loading  for  a given  bus  command  and  control  scheme  ? 

3.  Whot  i,  the  specific  assignment  of  signals  to  bits,  words  and  messages 
for  a qive'ri  bus  command  ai  d control  scheme  and  a given  signal  flow 
'1st? 

4.  What  redundancy  is  needed,  and  how  is  it  best  managed  ? 

5.  What  is  the  best  sequence  for  placing  informatio  on  the  bus  for  transfer  ? 

6.  How  many  terminals  are  needed,  and  how  should  signals  be  allocated  to 
terminals? 

7.  Should  processing  copacity  be  placed  in  the  terminals,  ana  if  so  how 
much  ? 

8.  What  is  the  impact  of  varying  multiplex  system  M l'BF  or  l;ie  cycle  cost: 
of  a fighter  aircraft. 

From  this  it  is  evident  that  List  2 can  contain  questions  (e.g.,  question  b) 
which  are  significant  and  wel l-on$wered  by  simulation,  but  foi  which  ihr  size  or  corro  e 
ify  of  the  implied  models  is  very  great.  Al  this  point  it  was  recalled  tia  ie  MiUXS.  v 
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host  system  is  a minicomputer  system  with  limited  memory  size  and  processing  "horse- 
power", and  questions  inconsistent  with  these  limitations  were  deleted.  This  step  consti- 
tuted Phase  three  of  the  three-phase  question  screening  process,  and  List  3 is  the  result- 
ant list  of  questions.  For  economy  of  description,  it  is  best  characterized  by  the  three 
screening  steps  mentioned  above,  rather  than  by  an  explicit  question  list. 

5.  TASK  GROUP  4 - IDENTIFY  MUXSIM  FUNCTIONAL  REQUIREMENTS 

Although  the  principal  functional  requirements  of  MUXSIM  are  largely  deter- 
mined (albeit  indirectly)  by  the  list  of  primary  tcrget  design  questions,  it  was  necessary 
to  proceed  further  and  give  explicit  requirements  for  MUXSIM  inputs,  outputs,  variables 
of  simulation,  control  mechanisms,  etc.  These  matters  are  covered  in  this  section,  wnich 
presents  an  integrated  functional  conceptua, -level  description  of  MUXS.M  as  a whole. 
This  is  the  major  result  of  the  Task  Group  4 effort.  The  description  is  that  of  a fairly 
large  and  comprehensive  simulator,  but  it  is  not  implied  that  the  first  version  of  MUXSIM 
built  should  implement  all  of  it.  It  is  primarily  provided  by  Figures  A-10  and  A— 11,  to- 
gether with  supporting  text  and  other  associated  figures.  Figure  A-10  provides  a very 
general  view  of  the  role  of  MUXSIM  in  the  avionics  multiplex  system  design  process, 
while  a more  detailed  functional  view  is  provided  in  Figure  A— 11.  These  are  the  key 
figures  in  this  system,  and  they  are  referred  to  often  in  the  discussions  that  follow. 

a.  MUXSIM  Inputs  (including  Variables  of  Simulation) 

Under  the  heading  of  Inputs,  the  following  subjects  are  covered  in  the 

indicated  sections: 

(1)  System  and  Workload  Description  Inputs 

(a)  Signal  Flow  Listing  (Level  2) 

(b)  Avionics  Systems  Listing  (Level  3) 

(c)  Air  Vehicle  Selection  (Level  4) 

(d)  Simulator  Inputs  (Level  1) 

(e)  "Prediction"  and  "Growth"  Inputs 

(f)  Canned  Inputs 

(2)  Simulator  Control  inputs 

(3)  Test  Bed  Inputs 

All  these  inputs  are  shown  in  Figures  A-'O  and  A-ll,  with  the  exception  of  test  bed 
inputs  which  are  treated  separately. 

Consider  first  Figure  A-10,  and  recall  that  the  basic  "real  world"  problem; 
that  MUXSIM  addresses  is  that  of  information  transfer.  Often  the  basic  problem  concerns 
some  futuristic  requirement  which  is  not  accurately  defined , and  which  implies  require- 
ments for  growth  and  flexibility  which  are  subject  to  judgment  or  prediction.  The  infor- 
mation  characterizing  and  influencing  the  information  transfer  system  requirements  is  that 
referred  to  as  "General  Inputs"  in  Figure  A-10.  That  information  which  describes  the 
candidate  information  transfer  system  which  is  supposed  to  meet  the  information  transfer 
requirements  is  referred  to  as  the  "Variables  of  Simulation"  in  Figure  A-10.  That  infor- 
mation which  tells  the  multiplex  system  designer  what  he  really  wants  to  know,  e.g.. 
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w ich  of  several  alternative  design  schemes  or  techniques  best  meets  the  requirements,  is 
referred  to  as  "Outputs  of  the  Simulation  Experiment."  It  should  be  noted  that  such  in- 
fo "mat  on  is  not  generally  the  result  of  a single  run  or  exercising  of  a single  model,  but 
rasher  is  ihe  result  of  a number  of  runs  on  c multiplicity  of  models,  which  in  the  aggre- 
gate may  be  referred  to  as  a "Simulation  Experiment,  " and  which  has  a different  meaning 
from  a simple  simulation.  Those  languages  which  assist  in  the  translation  from  a forma! 
description  of  rhe  multiplex  system  and  its  workload  to  a working  software  model  of  the 
multiplex  system,  "ogether  with  the  data  for  driving  the  model,  are  referred  to  as  "Simu- 
lator fnpif -mentation  Languages."  They  are  usually  either  general  purpose  programming 
language-.  or  general  purpose  simulation  languages. 

Next-  consider  Figure  A—  IT.  it  presents  a somewhat  different  bur  equivalent 
view  of  MUXSIM  inputs  and  outputs,  if  provides  a more  derailed  and  analytic  view  of 
the  situarion,  and  more  directly  supports  the  discussions  in  this  section.  Therefore  it 
should  be  regardeJ  as  the  primary  illustration  for  points  made  hereinafter. 

(1)  System  and  Workload  Description  Inputs 


In  order  to  use  MUXSIM  in  his  system  design  efforts,  the  multiplex 
q stem  designer  must  ultimately  provide  precise  formal  descriptions  of  both  the  alternative 
system  models  he  wishes  to  study  and  the  workloads  he  wishes  to  apply  to  those  models. 
However,  in  the  course  of  arriving  at  this  level  of  description,  which  is  referred  to  as 
Level  1 of  the  inputs  in  Figure  A-ll,  he  may  first  work  with  higher  level  and  more  in- 
direct descriptions  of  the  information  transfer  problem  from  which  he  subsequently  a.  es 
the  Level  1 inputs;  and  this  derivation  may  oe  by  manual,  semiautomatic,  or  automar.^. 
means.  These  higher  level  descriptions  are  referred  to  as  Levels  2,  3,  and  4 in  Figure 
A-l],  and  in  general  the  higher  the  level  of  the  input,  the  more  indirect  the  description 
of  the  information  transfer  system  that  it  embodies,  in  fact,  a Level  4 descriotion  may 
indirectly  describe  the  null  multiplex  system,  for  it  may  describe  a type  of  air  vehicle 
for  which  a multiplex  system  is  not  at  all  feasible.  The  entire  set  of  hierarchical  informa- 
tion input  levels  is  essentially  defined  as  or  effort  to  structure  the  multiplex  system  design 
process  in  such  a way  as  to  facilitate  the  application  of  computer-aided  design  techniques 
ai  different  stages  in  this  process.  The  blocks  shown  in  Figure  A-l]  are  discussed  below 
on  an  individual  basis. 

(a)  Signal  Flow  Listing  (Level  2) 

This  level  of  information  inputs  is  discussed  first  because  it  is  the 
primary  source  of  information  transfer  requirements  for  the  multiplex  system,  from  which 
the  Level!  inputs  must  subsequently  be  derived.  The  signal  flow  listing  consists  of  the 
individual  slgncis  which  carry  the  information  among  the  systems  within  ths  aircraft.  The 
T'Monics  signal  types  from  which  the  signal  flow  listing  is  derived  are  shown  in  Table  A-fV 
The  signal  flow  listing  itself  contains,  for  each  signal,  all  pertinent  information  required 
to  specify  the  signal  characteristics  which  ere  relevant  to  the  multiplex  sy.tem  design 
problem,  it  will  be  available  initially  in  the  form  of  a card  deck  and  will  contain  the 
information  shown  in  Table  A-V. 
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Table  A-IV.  AVIONICS  SIGNAL  TYPES 


v 


Discrete  (single  bi-level  channel): 

Information  is  in  the  signal  position. 

Analog  (single  continuous  channel): 

Information  is  in  the  time  duration  of  the  signal, 
information  is  in  the  amplitude  of  the  signal, 
information  is  in  the  amplitude  of  the  modulated  signal. 

Resoiver  (dual  continuous  channels): 

information  is  in  the  amplitude  of  the  two  modulated  signals. 

Synchro  (triple  continuous  channels): 

Information  is  in  the  amplitude  of  the  three  modulated  signals. 

Parallel  Digital  (multi  bi-level  channeis/time  dependent): 

information  is  in  the  signal  position  at  each  channel  during  a given  time  interval. 

Serial  Digital  (single  bi-level  channel/time  dependent): 

information  is  in  the  signal  position  during  a sequential  series  of  time  intervals. 

Pulse  (single  channel/time  dependent): 

Information  is  contained  in  the  time  that  the  pulse  occurs. 

Pulse  Rate  (single  channei/time  dependent): 

information  is  contained  in  the  number  cf  pulses  per  unit  time. 
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Table  A-V.  SIGNAL  FLOV/  LISTING  INFORMATION 


Signal  Name 

Name  assigned  to  identify  the  signal. 

Mission  Phase 

Identification,  by  listing,  of  the  various  phases  of  the  mission  where  this  signal 
might  be  used . 


Mission  Function 

Identification,  by  listing,  of  the  major  avionic  functions  of  which  this  signal  is  a 
part  (i.c.,  navigation,  communication,  etc.). 

Origin  Location 

Identification,  by  alphanumerics,  of  the  aircraft  X,  Y,  and  Z axes  of  the  origin 
LRU. 

Destination 

Identification,  by  listing,  of  the  LRU  where  the  signal  will  terminate. 

Destination  Location 

Identification,  by  alphanumerics,  of  the  aircraft  X,  Y,  and  Z axes  of  the 
destination  LRU. 

Equation  Number 

Identification,  by  alphanumerics,  for  signals  which  originate  or  are  delivered  to  a 
processor  (the  number  of  the  equation  in  the  computations  task  description). 

(Multiple  usage  will  result  in  multiple  listings  under  this  heading.) 

Multiplicity  N umber 

Identification,  by  numerics,  of  the  total  number  of  destinations  for  multi-destination 
signals.  The  signal  listing  will  be  repeated  for  each  usage  with  the  same  signal  name 
and  origin,  but  with  a different  destination . 

Signcl  Type 

Identification,  by  listing,  of  the  general  classification  of  the  signal  (i.e.,  discrete, 
dc,  analog,  synchro,  etc.). 

Frequency  Content 

Icentification  (where  applicable ),  by  numerics,  of  the  highest  frequency  in  Hz 
contained  in  the  informefion  portion  of  the  signal;  that  is,  the  highest  frequency 
contained  in  the  equivalent  baseband  transmission  of  the  signal. 

Update  Rat«? 

Icentification,  by  numerics,  of  the  number  of  times  per  second  that  the  signal 
would  have  to  be  transmitted  or  updated  in  a Time  Division  Multiplex  (TDM) 
sy>fem  to  satisfy  the  user  (destination)  requirements.  Note  that  this  is  a function 
of  particular  application  and  output  reconstruction  requirements. 

Quantization  (Resolution)  Bits 

laentification,  by  numerics,  of  the  number  of  signal  bits  that  the  particular  signal 
would  require  to  pass  the  information  to  the  user. 

Delay  Sensitivity 

Identification  (where  required),  by  numerics,  of  the  maximum  delay  in  milli- 
seconds which  the  signal  could  tolerate. 

Skew  Sensit  vify 

Identification  (where  required),  by  numerics,  of  the  maximum  skew  allowat  le  as 
a function  of  percent  of  the  uodate  period. 
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(b)  Avionics  Systems  Listing  (Level  3) 


Similar  types  of  equipment,  or  subsystems,  on  board  aircraft 
generally  have  the  same  data  requirements.  Moreover,  these  subsystems  usually  have 
their  equipment  distributed  within  the  same  physical  areas  of  their  host  aircraft  (i.e.,  the 
forward-looking  radar,  flight  control  system,  cockpit  and  its  associated  systems,  etc.). 

A useful  input  baseline  can  therefore  be  compiled  by  specifying  the  avionic  systems  con- 
tained in  the  vehicle. 

(c)  Air  Vehicle  Selection  (Level  4) 


Specific  classes  of  aircraft  have  similar  mission  requirements  Gnd 
consequently  similar  avionics  hardware  or  system  requirements.  Therefore,  an  input  base- 
line can  be  specified  from  which  an  effective  signal  flow  listing  can  be  compiled  by  simply 
specifying  the  aircraft  type.  Table  A-VI  shows  a classification  of  aircraft  types  which  is 
considered  suitable  for  this  application. 

(d)  Simulator  Inputs  (Level  1) 


As  Figure  A- 11  shows,  there  are  three  different  types  of  Level  1 
inputs:  "workload,  " "sequencing  and  control,  " and  "configuration  and  error/failure 
status."  The  latter  two  types  comprise  the  information  referred  to  in  Figure  A-10  as 
"Variables  of  Simulation,  " while  the  fo-mer  may  be  distilled  from  portions  of  the  informa- 
tion referred  to  in  Figure  A-10  as  "General  Inputs."  The  MUXSIM  user  must  specify  inputs 
at  Level  1 formally  and  precisely,  because  the  MUXSIM  system  itself  must  translate  from 
these  into  object  code  which  constitutes  the  multiplex  system  model  and  its  workload; 
therefore,  ambiguity  cannot  be  tolerated.  Our  present  discussion  will  cover  the  contents 
of  the  information  at  this  level,  but  not  its  format,  since  specification  of  the  latter  has 
not  yet  been  done.  Format  specification  is  one  of  the  primary  tasks  remaining  in  this 
study. 


There  is  an  intimate  relationship  between  Level  2 inputs  and 
Level  1 inputs  because  the  former  represents  a rather  precise  description  of  the  information 
transfer  requirements  for  which  Level  1 inputs  are  intended  to  be  a system  design  solution. 
From  these  requirements  can  be  derived,  by  various  means,  the  description  o':  both  can- 
didate multiplex  systems  and  “typical"  workloads  to  be  executed  by  such  systems.  Figure 
A-ll  is  intended  to  show  that  portions  of  this  derivation  can  be  performed  by  automat. c 
means,  i.e.,  with  the  aid  of  digital  computer  programs.  Such  programs  can  be  referred 
to  as  "simulator  input  generator"  routines.  Representative  tasks  for  these  routines  are: 

1)  the  task  of  making  optimal  assignments  of  signals  to  remote  terminals;  ard  2)  the  task 
of  deriving  information  traffic  statistics  which  are  typical  of  anticipated  real  world  traf- 
fic situations  for  the  multiplex  system.  The  latter  task  is  of  great  importance,  because 
even  a valid  model  of  a multiplex  system  cannot  be  used  to  fully  demonstrate  adequacy  of 
the  design  unless  the  model  is  driven  by  a realistic  workload. 

At  Level  1,  "configuration"  inputs  are  those  which  declare  what 
the  component  subsystems  of  a multiplex  system  are,  while  "sequencing  and  control"  in- 
puts are  those  which  describe  the  interconnections  and  interactions  of  these  subsystems 
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Table  A- VI . CLASSIFICATION  OF  AIRCRAFT  TYPES 


Close  Air  Support 


Air  Superiority 


• Interceptor 


Bomber/Strategic 


Photo  Reconnaissance 


Surveillance 


Gunship 


f 


Day 
^ Night 

Night/All  weather 


i 


Day 

Night 

Night/All  weather 


All  Weather 


Light 

Medium 

Heavy 


Infrared 


Electronic 


• Countermeasures 


! 


during  actual  system  operation.  In  MUXSIM,  the.c  subsystems  and  their  interactions  are 
implemented  by  generalized  functions  ond  by  the  cor  rol  program  which  sequences  these 
functions  and  provides  communications  between  them.  " Error/fa i lure  status"  inputs  are  a 
special  type  of  configuration  inputs  which  describe  the  "health"  of  the  component  subsys- 
tems. Thus,  the  MUXSIM  user  may  declare  that  a certain  subsystem  has  failed  or  is  pro- 
ducing intermittent  errors,  and  by  running  his  simulation  model  in  this  condition  he  may 
check  for  adequate  redundancy  managemenr  behavior  and  for  adequate  performance  in  the 
presence  of  errors. 


"Workload"  inputs  are  those  that  describe  the  input  information 
flow  which  it  is  the  job  of  the  multiplex  system  to  manage.  Thus,  the  workload  inputs  de- 
scribe input  information  traffic  scenarios  which  may  vary  widely  in  sophistication  from  a 
simplistic  workload  which  generally  checks  for  minimal  system  functioning,  to  a complex 
workload  which  portrays  varying  information  traffic  loads  during  several  phases  of  a com- 
plete aircraft  mission.  These  inputs,  like  the  other  Level  1 inputs,  must  be  supplied  pre- 
cisely and  formally  in  accordance  with  a specific  format  which  has  not  yet  been  developed. 

(e)  "Prediction"  and  "Growth"  inputs 


As  previously  discussed,  a system  is  often  studied  (by  the  use  of 
the  simulator)  in  the  context  of  some  future  application  for  which  the  exact  requirements 
are  usually  unknown.  In  such  cases,  the  oniy  factors  that  might  be  definable  are  the  air- 
craft type  and  possibly  the  equipment  types  that  are  to  be  used  in  the  aircraft.  Level  3 
and  Level  4 inputs  are  intended  to  be  of  use  here,  and  they  have  to  be  modified  to  accom- 
modate anticipated  aircraft  systems  growrh  and  expansion  requirements.  Although  the  de- 
signer's crystal  ball  is  murky,  he  may  have  some  feel  for  anticipated  future  developments 
and  for  trend  predictions.  These  are  discussed  next. 

Anticipated  Future  Developments 

Usually  the  best  information  available  is  that  for  present  equip- 
ment. One  forecasting  approach  is  to  modify  such  information  through  engineering  judg- 
ment on  a signal-by-signal  basis.  Among  the  points  that  need  to  be  considered  are  future 
developments  resulting  from  programs  concerning  integrated  Controls  and  Displays,  Digital 
Flight  Control  Systems,  and  other  such  systems.  For  example,  Integratec  Controls  and 
Display  Systems  reduce  the  number  of  interfaces  in  the  cockpit,  while  other  programs  such 
as  Standard  Interface  will  reduce  the  numbe-  of  different  interfaces  between  equipments. 

In  fact.  Standard  interface  may  eventually  result  in  a single  serial-digital  interface. 

Other  programs  promoting  Integrated  Digital  Avionics  may  reduce  tie  overall  equipment 
communications  requirements  by  making  more  efficient  use  of  information.  With  knowl- 
edge of  which  programs  are  likely  to  impact  the  multiplex  system  design  proolem,  the  user 
can  create  a Signal  Flow  Listing  which  has  been  manually  modified  to  incorporate  such 
anticipated  changes. 
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Trend  Predictions 


A second  forecasting  approach  involves  the  creation  of 
trend  predictor  curves  which  can  be  applied  in  a statistical  manner  to  modify  the  Signal 
Flow  Listing . A program  cculd  be  written  to  make  these  changes  automatically.  An 
automatic  method  like  this  would  typically  involve  user-selected  trend  predictors.  For 
example,  a u^er  interested  in  general  information  might  need  a trend  predictor  method 
that  'vou'd  work  by  simply  keying  in  the  future  year  of  interest,  together  with  other  in- 
purs u:>jci  in  calling  up  conned  data.  Trena  predictors  would  be  based  on  factors  such  as 
Integrated  Avionics.  Integrated  Controls  and  Displays,  etc.  Some  typical  predicvor 
curves  are  shov/n  in  Figure  A-12.  Even  a Level  i user  who  specifies  simulator  Inputs 
directiv  can  use  trend  predictor  techniques  to  modify  his  original  data,  and  thereby  check 
the  adequacy  of  his  results  In  the  light  of  various  future  possibilities. 

In  conclusion,  a canned  routine  for  automatic  modifica- 
tion of  the  signal  flow  !isting,cal led  a "prediction  and  growth  modifier,"  may  be  a desir- 
able feature  of  the  MUXSIM  system.  The  relationship  of  this  routine  to  the  rest  of  the 
MUXSIM  system  is  shown  explicitly  in  Figure  A- 11. 

(f)  Canned  inputs 

MUXSIM  inputs  can  be  placed  in  two  categories:  "canned" 
and  "original".  "Canned"  types  are  those  that  the  user  can  define  with  a minimum  jf 
effort.  They  are  expected  to  be  most  useful  either  during  that  phase  of  the  develop  o' 
program  when  the  design  problem  has  iittie  definition,  or  when  the  user  is  merely  address- 
ing genera!  classes  of  vehicles.  "Original"  types  are  those  that  the  user  enters  Into  the 
MUXSlA'I  manually.  They  are  needed  when  the  user  has  a problem  of  evaluating  a system 
which  is  different  from  those  easily  definable  by  use  of  existing  canned  routines.  Once 
defined,  an  original  input  can  readily  become  a canned  routine,  it  is  also  anticipated 
that  there  will  exist  a requirement  for  inputs  which  are  combinations  of  conned  and  orig- 
inal types.  Several  sets  or  canned  inputs  are  to  be  resident  within  the  MUXSIM  sys.em. 
in  Figure  A- 11  these  canned  routines  comprise  the  blocks  referred  to  as  "Prediction  and 
Growth  Modifiers, 11  "Factor  Library,"  and  "Workload  Library."  Their  relationship  fo  the 
remainder  of  MUXSIM  is  indicated  in  the  figure.  At  present,  these  blocks  are  included 
in  the  illustration  as  a conceptual  aid,  and  neither  the  exact  contents  nor  the  forrnars  of 
these  canned  sets  are  presently  well-defined.  Many  factors  are  relevant  to  decisions 
concerning  their  exact  nature  and  form.  Among  the  most  important  factors  are  MUXSiM 
implementation  cost  and  schedule  guidelines. 

(2)  Simulator  Control  inputs 

Simulator  control  inputs  are  those  inputs  which  provide  informa- 
tion about  the  desired  simulator  mode  of  execution,  and  about  *he  desired  selection  and 
presentation  of  simulator  outputs.  For  example,  in  the  debug  phase  of  a MUXSIM  mo'.U 
development  it  may  be  desirable  to  have  the  simulator  run  for  short  intervals  in  the  traco 
mode,  using  certain  simple  standard  workload  inputs  for  which  outputs  ere  known.  In 
later  phases,  longer  runs  with  more  complex  workloads  and  hard-copy  outputs  may  be  de- 
sired. Simulator  control  inputs  will  aiiow  the  MUXSIM  user  to  select  these  modes  of 
operation  according  to  his  needs.  Details  of  these  inputs  remain  to  be  developed. 
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Figure  shows  how  the  total  information  transfer  requirements  for  a fixed  set  of 
avion! cs  functionsmight  decrease  with  time.  Such  a reduction  could  be  due  to 
a decrease  in  the  amount  of  redundant  information  transferred  in  an  integrated 
avionics  system . 

Figure  shows  the  reduction  in  information  transfer  requirements  that  might  be 
achieved  in  future  for  a fixed  set  of  avionics  functions.  This  reduction  would 
be  due  to  use  of  integrated  avionics  systems,  and  is  shown  by  avionics  signal 
type. 


Figure  A-12.  Typical  Trend  Predictor  Curves 
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(3)  Test  bed  lnpv.*s 

e only  anticipate!  requirement  it  the  MUXSIM  System  wi  . 
hove  for  '-eol-time  inteifa  o(  o hardv  are  exerc  ser,  or  test  bed. 

Inputs  associated  with  ‘‘vs  function  are  not  shown  in  Figure  A-l  I . Because  of  the  as-.C'' 
ated  real-time  requirements,  the  simulator  will  probably  not  be  able  to  run  elaborate  pro- 
grams in  this  node  >per  ir  tead,  simulator-to-hordwore  communications  will  p-c- 
ahly  be  honaiea  on  a , uble  - lookup  basis. 

Th  ' communications  will  be  conducted  through  a special-purpo 
I/O  contro'  uni i . Outputs  from  the  simulator  to  the  hardware  wiii  be  reac  out  seque  .tic 
upon  request  f-om  he  I/O  control  unit.  Inputs  from  the  hardware  being  tested  will  simp! 
oe  o ought  in  f.orn  I/O  contro*  unit  and  compared  with  information  contained  in  simu- 
lator table  . Either  c single  multiplex  system  unit  or  an  entire  multiplex  system  con  re 
tested  in  this  manner  (see  Figure  A-8).  In  either  case,  the  simulator  inputs  will  be  pro- 
vided by  loeding  into  the  simulator  a table  containing  all  the  detailed  information  required 
by  the  hardware  being  tested.  These  inputs  will  be  pre-prepared,  either  manually  or  by 
processing  of  information  obtained  during  the  running  of  other  nori-real-time  simulations 

b.  MUXSIM  Outputs 

The  identification  of  MUXSIM  outputs  was  the  most  difficult  task  in  . 
MUXSIM  definition  phase.  One  way  to  arrive  at  this  identification  indirectly  is  e ev 
MUXSIM  as  a multiplex  system  analysis  tool,  and  to  determine  the  set  of  designer  es- 
tion;  which  the  tool  should  be  most  helpful  in  answering.  This  aoproach  has  been  r 
in  paragraph  4.  That  material  will  not  be  cohered  again  here,  but  because  of  he  crucial 
importance  of  the  MUXSIM  outputs,an  equivalent  rationale  ^or  their  determination  is  pre- 
sented below.  The  context  for  the  discussion  is  the  overall  multiplex  system  design  process. 

The  requirements fo>  a multiplexed  Information  Transfer  System  are  a prime 
consideration  throughout  the  conceptual  design  stages  of  any  military  air  vehicle.  These 
requirements,  when  combined  with  the  air  vehicle  subsystems  requirements,  yield  major 
design  decisions  concerning  the  level  of  sophistication  of  the  information  transfer  system. 
The  resultant  system  may  be  as  complex  as  a multiple-bus  system,  which  uses  a separate 
information  transfer  system  for  each  major  air  vehicle  function,  such  as  avionics,  weaon 
stores  management,  electrical  power  distribution  and  performance  monitoring.  At  the  ex- 
treme other  end  of  the  selection  scale  is  an  information  transfer  system  which  aoes  not  use 
multiplexing  at  all. 

The  multiplex  system  design  process  is  both  interactive  and  iterative 
and  varies  widely  in  complexity.  For  instance,  if  the  air  vehicle  equipments  are  d sign, 
to  meet  a Standard  Interface  Requirement,  then  a multiplexed  inrormation  ransfer  yste! 
may  be  easily  implemented.  Likewise,  the  process  is  simplified  if  there  is  a commoner t 
of  design  between  ihe  nir  vehicle  subsystems  which  would  allow  hem  to  use  a common 
information  transfer  system  . In  any  event,  the  decision  made  during  the  preliminary  de- 
sign phase  will  be  one  of  the  following  three: 
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Select  multiple  multiplexed  information  transfer  systems,  with 
each  system  serving  a major  A/V  partition  (multi-bus  system). 


• Select  a single  multiplexed  information  transfer  system  which 
serves  one  or  more  A/V  partitions  (single-bus  system). 

• Select  a non-muitiplexed  system  (no  bus  system). 


MUXSIM  must  provide  insight  and  guidance  at  this  point  in  the  design 
phase,  and  yet  not  consume  vast  amounts  of  time  and  effort  in  a complex,  total  system 
evaluation.  To  facilitate  attainment  of  this  gocl  we  define  three  categories  of  outputs: 
Functional,  Operational,  and  Other.  These  are  discussed  next. 


(1 ) Functional  Outputs 

The  functional  outputs  of  MUXSIM  are  those  which  tel!  the  user 
if  the  system  he  has  hypothesized  will  wo'k  correctly  and  with  at  least  adequate  nominal 
and  error/fault  performance.  And,  if  it  does  not  work  properly,  the  functional  outputs 
will  tend  to  indicate  why.  As  an  example,  one  may  consider  a system  with  message  pri- 
ority where  high  priority  messages  in  the  first  terminal  accessed  can  prevent  access  to  the 
remaining  terminals  in  the  system,  regardless  of  the  priority  of  their  messages.  This  prob- 
lem is  caused  by  a conceptual  design  error,  and  a detailed  simulation  of  this  system  is 
unwarranted. 


The  need  for  functional  outputs  grows  as  information  transfer 
systems  grow  in  complexity  by  the  addition  of  features  such  as  priority,  store  and  forward, 
multiple  channel  with  channel  selection,  and  sophisticated  redundancy  management 
schemes.  These  features  add  so  many  complex  logical  interactions  to  the  system  that  sim- 
ulation becomes  the  only  practical  way  to  determine  their  effects. 

Simulation  languages  such  as  GPSS,  GASP,  and  SIMSCR1PT  offer 
means  for  easily  obtaining  functional  outputs.  This  is  particularly  true  when  the  system 
model  is  operated  step  by  step  to  observe  its  detailed  behavior  when  errors  are  introduced 
to  the  various  system  elements.  This  type  of  functional  check  is  particularly  effective  in 
verifying  redundance  management  schemes  or  the  system's  proper  reaction  to  failures. 

That  is,  given  that  a system  failure  is  sensea,  does  the  switch  to  a redundant  element 
occur  in  an  orderly  manner? 

The  output  from  a program  simulated  in  one  of  fnese  languages 
normally  allows,  as  a minimum,  a trace  of  the  simulator  elements  or  blocks  through  which 
the  data  has  traveled.  This  trace  can  verify  the  designer's  intended  data  flow.  Also,  the 
time  of  arrival  of  the  data  at  each  model  element  can  be  continuously  updated  and  eval- 
uated for  data  delay,  skew,  and  late  and  early  arrivals.  With  these  minimum  outputs  the 
systems  designer  can  perform  a great  deal  of  "before  the  fact"  debugging,  where  the  po- 
tential savings  in  time  and  money  are  greatest.  The  data  required  to  simulate  a system  at 
this  level  is  normally  neither  great  in  volume  nor  detailed.  Certainly  the  model  need  not 
be  more  detailed  than  the  "shift  register"  or  "arithmetic  unit"  level,  and  even  that  level  of 
detail  may  not  be  required  to  obtain  meaningful  results. 
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Some  of  he  'ore  I .-eqj.rer  • -nt.»  expected  tc  be  obroinec  .1 

s'  3le  mod*  c-  n "u’tip'ex  system  ore  cs  folio*.,: 

* Average  system  b‘t  rare  rear1  en.ents 
o Maximum  system  sit  rate  requirements 

* Average  sysrem  dala  transfe  capacity 
«.  Maximum  system  data  transfer  capacity 

* Average  system  dote  transfer  reserve  capaci*/ 

a Minimum  system  data  transfer  reserve  capacity 
a Maximum  data  transfer  aeiay 
« Average  ccfa  transfer  aeiay 

* System  reaction  to  faults 

If  severe!  diffsren  multiplex  systems  are  modeled  by  changing 
the  variables  of  sim.iiuiLc,  and  if  these  models  are  exercised  with  varying  workloads, 
<hen  a more  comorehensive  "simulation  experiment"  will  have  been  performed.  In  such 
a case.  The  following  types  of  outputs  may  Pe  obtained: 

» Optimal  number  of  remote  terminals 
v-  Optimal  placement  of  rem  te  terminals 
« system  bit  rate  requirement- 

(2)  Operational  Outputs 

Or.ce  a final  system  configuration  has  been  tentatively  selected 
and  its  correct  logical  behavior  established,  more  detailed  outputs  may  be  obtained  fro 
the  simulation  mod.;!.  The  resultant  information  collected  concerns  how  well  the  r/stc  1 
operates  rather  than  simply  "does  it  work?"  This  data  con  provide  specific  information 
which  con  be  used  for  “tuning"  the  design  for  optimal  performance.  Examples  of  outout, 
containing  this  more  detailed  information  ore  the  following: 

a System  performance  with  "worst-case"  workloads 

9 Average  and  maximum  utilization  of  various  system 
resources: 

--bus  utilization 

— control  unit  utilization 

-"terminal  unit  utilization 

e Probability  of  lost  data 

9 Probability  of  undetected  erroneous  data 
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«*  Probability  of  iate  data 

• Average  and  maximum  data  skew  and  jittering 

• Nominal  end  worst-case  sync  behavior 

• Detailed  system  queuing,  priority,  and  interrupt  behavior 


(3)  Other  Outputs 

The  multiplex  system  designer  must,  by  one  means  or  another, 
provide  additional  information  regarding  a candidate  multiplex  system  design.  Although 
suer,  information  must  be  an  output  of  his  design  study,  it  is  not  necessarily  a direct  output 
of  MUXSIM. 


Examples  of  these  "other"  outputs  follow; 

• System  cost 

• System  weight 

• System  size 

• System  reliability 

• System  maintainability 

o System  performance/cost 

• System  power  requirements 

• Internal  subsystem  layout  preferences 

Because  these  outputs  require  information  which  may  be  difficult 
to  quantify  or  otherwise  incorporate  into  MUXSIM,  they  are  not  presently  contemplated 
as  direct  outputs  from  MUXSIM.  However,  it  is  expected  that  the  existing  MUXSIM  out- 
puts can  be  used,  together  with  other  information,  to  produce  these  outputs  after  addi- 
tional manual  or  automatic  manipulation.  As  MUXSIM  evolves,  it  may  be  possible  to 
include  some  of  these  outputs  as  direct  outputs  of  its  future  versions. 

c,  MUXSIM  Implementation  and  Design  Recommendations 

The  main  purpose  of  the  MUXSIM  definition  phase  was  to  produce  a 
functional  definition  or  description  of  MUXSiM.  Ideally  such  a definition  should  specify 
what  functional  capabilities  MUXSIM  should  have,  but  not  how  they  should  be  imple- 
mented. However,  it  has  been  noted  previously  that  the  MUXSIM  functional  definition 
has  been  significantly  influenced  by  a knowledge  of  what  the  intended  MUXSIM.  host 
system  was  to  be  (i.e.  the  DEC  PDP-11/45).  This  knowledge  played  a role  in  restricting 
the  scope  of  MUXSIM. 
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Other  studies  condui  eo  during  the  MUXSIM  definition  phase,  dis- 
cussed earlier,  led  to  a set  of  recommendations  f...,  MUXSIM  implementation  and  design 
procedures.  Although  these  ore  " ' i.uiy  ft  actional  requirements,  if  was  felt  that  they 
were  valid  and  significant  inputs  for  me  MUXSIM  design  pease.  ihey  are  stared  below. 

e To  reduce  MUXSIM  initial  development  costs  anci  to  facilitate 

later  chonges,  the  highest  level  implementation  language  feasible 
should  be  used.  Specifically,  GASP  and/or  Fortran  should  be 
used  as  primary  implementation  languages  for  the  Simulator. 

« 7 lie  .us;  bed  mod,,  o'  MUX  M op  oration  should  be  considered  as 

separate  irorn,  and  independent  of,  other  modes  of  operation. 

<*  The  non-test-becl  portion  of  MUXSIM  should  be  considered  mainly 
as  software,  with  little  or  no  special  hardware  required. 


To  ensure  MUXS  V\  feasibility  and  relevance,  MUXSIM  specifica- 
tions should  be  ceve'  fed  in  parallel  with  a smail-scale  simulation 
exercise  in  mad-.h  and  simulate  those  areas  of  the  B-l  FMUX  system 
which  have,  in  hindsight,  caused  the  most  design  problems,  and 
wherein  early  simulation  could  apparently  have  done  the  most  to 
alleviate  those  problems.  An  example  of  such  a problem  area  is 
that  oi  redundancy  management.  MUXSIM  specifications  should 
be  developed  in  part  by  generalization  of  the  smail-scale  simula- 
tion modei  developed  for  B-l  EMUX  analysis. 
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SECTION  IV 

PHASE  2 - MUXSIM  DESIGN 


1.  INTRODUCTION 

Th-  MU/vSIM  design  phase  was  basically  a three-step  process  which  starting 
fro-  a MuXSiM  !'  'Mono-  description  and  requirements,  proceeded  to  the  'elopment 
of  a MUXSIM  .'es.'g-  cification.  This  process  is  illustrated  in  Tow  chart  arm  n 

. : . re  ia  . an.  description  one  requirements  . hich  servea  as  the  inpur  tc 

tt  phase  were  produ  : i *.s  principci  output  of  the  preceding  definition  phase. 

Th  is  . f rc  consists  mo  inly  of  a discussion  of  the  How,  What  and  Why  of 
/v  ' 0 SIM  des  an;  how  the  process  was  conducted,  what  design  resulted,  and  why  variot 
•ic  n decisions  wee  made.  However,  tor  the  sa<e  of  brevity  this  discussion  wiii  be  in 
sun  ' ary  form  only.  The  reader  interested  in  full  detail  may  find  it  in  the  Second  Interim 
Technical  Report  (ref.  6),  which  consists  of  four  volumes  containing  about  750  pages 
altoaether. 


In  genera!  the  design  process  was  straightforward,  and  resuited  in  a design 
consistent  with  both  the  input  functional  requirements  and  the  associated  desig1  and 
implementation  recon  r endations . The  oniy  exceptions  to  this  were  two:  '!)  tn  3. 
ment  hr  a real  -r  me  or  test-bed  MUXSIM  mode  was  dropped,  with  Air  Force  opp  ova. 
and  (2  certain  MUXSIM  our  puts  weie  codec  which  ore  useful  in  the  multiplex  system 
production  proces:  (i.e.,  in  software  or  hardware  development)  hut  which  are  not  limy 
tion  outputs  in  a strict  sense.  The  additional  outputs  were  easily  provioed  as  a by-product 
of  existing  MUXSIM  models  end  processes,  end  serve  tc  ncrease  its  value  considerably 
in  real  system  developments. 

The  partitioning  of  design  tasks  was  such  that  Tasks  1 , 2 end  3 in  Figure 
A- 13  were  necessarily  executed  sequentially,  but  much  of  the  detail  design  of  subsystem 
(done  in  Tusk  2)  was  accomplished  in  parallel.  This  particular  organization  of  the  des  on 
effort  was  quite  effective  in  reducing  overall  design  time.  In  the  following  sections  the 
how,  what  and  why  of  the  three  identified  design  tasks  are  discussed  separately. 

2.  TASK  1 - SYSTEM  FUNCTIONAL  DESIGN 

The  MUXSIM  functional  definition  produced  in  Phase  1 described  what 
cap-b'lities  MUXSIM  should  have  and  what  it  was  to  be  used  fo1-,  but  it  die  not  adec.  atelv 
describe  how  MUXSIM  was  to  be  used,  in  short,  it  did  not  provide  o well-dotined  MUXSI ‘ 
User  interface  definition;  and  this  was  a significant  omission,  because  ease  c use  was 
or.  evident  MUXSIM  design  goai.  Also  there  were  certain  other  weakly  defined  areas, 
notable  among  them  being  tire  orea  of  test  mode  requirements. 


7 9 


Figure  A-13.  MUXSIM 
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The  letter  pi  obit  n wos  quickly  resolved  by  tnc  ceittion  ot  , . J/»u;iVi  -es. 
n , Mi  orceagi  ement.  The  former  problem  was  resolved  by 
cbvelcpme.it  of  a MUXSiM  use  model  together  wifi  a prof  i .-  cc  a typicoi  MUXS1M  use  , 
ant  tnese  led  ro  c set  of  i n.'',  -.merits  for  the  MUXSlM-user  Interface. 


Thu  VUJXSIM  <!■■}  mode  developed  was  that  for  a typical  simulation  experi- 
ond  a simp)  ied  ver  1 of  it  is  given  in  Figure  A-14.  It  contair  s five  tops,  wl  3 - 
are  d’  r usted  below: 


Step  : - System  Definition 

In  th.  step  he  system  !o  be  studied  is  defined.  A typical  definition  wii! 
take  the  orm  of  an  annotated  block  diagram.  his  bioc  ; diagram  need 
be  precise,  serving  mainly  as  a iocse  semiformal  description  of  what  is 
desired . 


Step  2 - Modei  Building 

In  this  step  the  following  must  be  specified  in  a precise  manner,  suitable 
for  inout  to  c computer: 

System  configuration  (specification  of  system  components) 

System  sequencing  end  control 
System  workload 

System  status  ond  environment  (Manures  or  .ystem  co  .oncu.s, 
errors  in  system  inputs; 

System  monitoring  and  outputs  (system  performance  dare  co  c 1 c 
data  analysis,  and  output  ormats). 

Step  3 - Simula  ion_ 

At  simulation  time,  items  such  as  the  following  must  be  spec.. Dec  in  c 
precise  manner; 

<»  Simulation  run  mode  (e.g.,  with  or  without  trace) 
o Simulation  run  termination  conditions 

End  after  a ccrrain  omojnt  ot  nuiated  time 
- End  after  a certain  amount  of  e'opsed  time 
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STEP  1 
STEP  2 
STEP  3 

STEP  4 
STEP  5 


Figure  A-14.  MUXSIM  Use  Model  for  a Simulation  Experiment 
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End  afier  a certain  logical  condition  achieved 
End  after  certain  error  conditions 
End  after  a certain  amount  of  output  generated 
# Other  simulation  run  options 

Trace  mode  (selective,  full) 

User  intervention  modes  (user  switch  settings,  etc.) 

Selected  output  devices  (e.g.,  printer  or  display  terminal) 

Various  other  options  can  be  imagined,  although  they  ere  not  necessarily 
feasible.  For  example,  the  user  might  have  a choice  of  compilers  which 
optimise  on  either  compiler  time  or  run  time,  as  is  the  case  with  the  IBM 
360  Fortran  G and  hi  compilers  and  with  IBM  360  PI./1  compilers. 

Step  4 - Evaluation 

Following  a simulation,  evaluation  of  the  results  of  the  run  is  normally 
accomplished.  Some  of  the  evaluation  can  be  done  automatical!/, 
involving  programmed  analysis  and  display  of  raw  data  obtained  cs  oi  tpur 
from  ;he  simulation.  The  more  of  the  evaluation  that  can  be  don  . auto- 
matically, the  easier  the  simuia.oi  is  to  use,  but  an  extensive  automatic 
evaluation  capability  can  add  substantially  to  the  simulator  cos  . 

Step  5 - Decision 

The  exact  nature  of  the  decision  step  depends  on  the  use  mode  of  rhe 
simulator.  If  the  simulator  is  being  used  primarily  for  reseat  eh  studies  of 
system  performance,  and  sensitivity  to  variation  of  certain  system,  parcme:ers, 
then  the  decision  after  a run  has  to  do  with  whet  parameters  to  very  next 
and  in  what  manner.  However,  if  the  question  revolves  around  v'h  c--  of 
two  possible  systems  is  best  for  a specific  development  program  , then  the 
exercise  is  concluded  after  both  systems  have  been  simulated  for  the  ame 
workload  and  error/failure  environments  and  the  better  of  the  two  selected 
Although  the  decision  step  can  be  partially  autometed,  human  ;udgment 
will  probably  be  the  principal  ingredient  here  for  the  foreseeable  future  of 


MUXSiM. 


In  addition  to  the  use  model,  a typical  MUXSIM  user  was  defined  in  terms 
of  computer  and  multiplex  system  design  background  requirements.  Since  these  assumea 
requirements  are  covered  specifically  in  Appendix  II,  they  will  not  be  repeated  here. 
Taken  together,  the  MUXSIM  use  model  and  the  typical  user  profile  provided  a basis  for 
design  of  a MUXSIM  which  was  "easy  to  use". 

A number  of  other  design  requirements  were  explicitly  identified  as  part  of 
Task  1 efforts.  These  included: 


Design  Requirements 


• Models  should  be  valid  and  realistic,  and  both  aspects  should 
be  demonstrable. 

• Workloads  should  be  demonstrably  realistic,  or  else  real  workloads. 

• Outputs  should  be  useful,  meaningful,  and  in  easily  interpreted 
formats. 

• Cost  of  simulation  runs  should  not  be  excessive. 

• MUXSIM  user  training  requirements  should  be  minimal. 

• MUXSIM  implementation  should  be  flexible,  to  allow  easy  change 
or  modification. 

• MUXSIM  design  should  be  compatible  with  the  capabilities  of  its 
planned  host  computer  system  (the  DEC  PDP-11/45). 

• MUXSIM  design  should  be  compatible  with  a reasonably  low  cost 
implementation  effort. 

• MUXSIM  should  be,  in  the  fullest  sense,  cost-effective. 

Although  many  of  these  requirements  fall  into  the  category  of  common  sense, 
many  simulators  have  been  developed  which  do  not  meet  them.  For  example,  some  sim- 
ulators have  been  built  which  are  so  hard  to  use  that  they  are  in  fact  not  used  at  aii, 
while  others  are  so  expensive  to  run  that  economics  prohibit  their  use.  Recently,  the 
highly  publicized  "limits  to  growth"  simulations  have  been  strongly  criticized  on  the 
grounds  that  the  models  implemented  are  invalid  or  that  input  data  is  unrealistic.  It 
was  a goal  of  MUXSIM  design  to  avoid  all  the  above  simulation  pitfalls  if  possible. 

Guided  by  the  MUXSIM  functional  definition  and  with  the  user  interface 
and  the  above  design  requirements  established,  the  Task  1 effort  concluded  with  the 
specification  of  the  MUXSIM  system  functional  design.  This  describes  MUXSIM  as  a 
system  consisting  of  four  major  subsystems,  as  shown  in  Figure  A-15.  The  four  subsystems 
and  their  functions  are: 
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operator 


INTERACTIVE 

EXECUTIVE 

SUBSYSTEM 


DYNAMIC 

SUBSYSTEM 


STATIC 

SUBSYSTEM 


UTILITY 

SUBSYSTEM 


MUXS1M  Moduicr  Software  Structure 


• Executive  Subsystem:  permits  operation  from  a CRT  or  TTY  terminal. 
Has  an  interactive  section  which  can  be  switched  on/off,  to  aid  the 
user  and  facilitate  learning  the  simulator  operations.  Controls  other 
subsystems . 

• Utility  Subsystem:  manages  the  signal  flow  list  and  extracts  the 
simulator  inputs  (workload)  from  it.  Uses  the  signal  flow  list  to 
check  the  Equipment  Complement  for  completeness,  flagging  any 
equipment  and  signal  deficiencies. 

• Static  Subsystem:  handies  the  remote  terminal  loading  task,  as 
well  as  the  fixed-telemetry  format  message  structure  and  bus  loading 
and  utilization  computations. 

• Dynamic  Subsystem:  handies  the  random  message  scheduling  task, 
and  computes  the  bus  loading  and  time  statistics  (facilities  of  GASP 
to  be  used  in  providing  these  functions). 

The  MUXSiM  partition  shown  in  Figure  A-15  is  a functional  one  in  which 
the  four  partitions  shown  are  essentially  functionally  independent.  In  addition,  the 
inter-subsystem  interfaces  are  relatively  ciecn  and  easy  to  implement.  Because  the  four 
subsystems  were  functionally  independent,  it  was  possible  to  conduct  design  tradeoff 
studies  and  determine  their  detail  designs  both  independently  and  concurrently.  This 
design  effort  is  the  subject  of  the  next  section. 

3.  TASK  2 - SUBSYSTEM  DETAIL  DESIGN 

Although  the  four  major  MUXSIM  subsystems  are  ail  functionally  different, 
the  methods  used  in  arriving  at  detail  designs  for  all  of  them  were  similar.  This  was 
because  all  subsystem  designs  shared  the  same  goals  and  requirements,  notable  among 
which  were: 

• Need  to  fit  on  a small  computer  system  (the  DEC  PDP-il/45) 

• Need  to  produce  meaningful  and  useful  outputs 

• Need  to  use  real  or  realistic  inputs 

9 Need  to  include  real  or  realistic  models 

As  a result,  the  design  efforts  were  all  characterized  by  a series  of  small 
probe  coding  exercises,  each  of  which  was  intended  to  produce  meaningful  and  useful 
results  related  to  some  aspect  of  an  existing  real-world  multiplex  system  design  problem. 
For  most  of  the  exercises,  the  real  problem  was  also  the  same,  namely  the  design  of  the 
U.  S.  Air  Force  Avionics  Laboratory  DAIS  Multiplex  Core  Element.  Thus,  for  example, 
the  Utility  subsystem  exercises  focused  on  the  actual  signal  flow  list  for  the  A-7D  aircraft 
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and  suirable  massaging  thereof,  while  the  Static  Subsystem  exercises  focused  on  data  transfer 
models  and  techniques  compatible  with  the  Air  Force  multiplex  standard  MIL-STD-1 553.  The 
thrust  was  to  develop  specific  programs  which  clecrly  produced  useful  and  realistic  results  crc 
would  fit  on  a small  system,  and  to  generalize  thereon  later.  This  method  was  suitable  for 
developing  and  testing  software  techniques  and  algorithms,  and  for  determining  specifics  of 
inputs  and  outputs;  moreover  it  provided  an  environment  which  stimulated  ideas  for  new  MUXSI'/i 
functions,  and  ways  to  implement  them.  A major  benefit  was  that  the  method  provided  a reiicb  ■ 
basis  ror  subsequent  MUXSIM  sizing  exercises  (required  number  of  lines  of  source  code,  number  r 
object  code,  size  of  data  base,  etc.)  In  brief,  the  design  method  used  could  be  described  as  a 
piecemeal  sofrware  breadboard  technique.  Some  specifics  of  the  individual  subsystem  " breadboards’ 
are  covered  next. 


a . Utility  Subsystem 

The  Utility  Subsystem  breadboard  consistea  of  a collection  of 
Fortran  programs  and  subprograms  (about  1300  lines  of  source  code).  They  massaged  the 
Signal  Flow  List  data  in  various  ways  to  facilitate  LRU-to-terminal  assignments,  and  to 
verify  the  validity  of  the  data  and  of  the  particular  LRU-to-terminal  assignments  that 
were  made  The  Signal  Flow  List  used  was  the  actual  one  for  the  A-7D  aircraft;  and  it 
was  initic ’ ’y  available  on  punched  cards.  It  contained  about  2650  signals,  and  each 
signal  had  a number  of  associated  parameters.  Altogether  the  A-7D  signal  flow  list 
comprised  a card  data  base  of  about  10,700  cards. 

b . Static  Subsystem 

The  Static  Subsystem  breadboard  consisted  mainly  of  a synthetic 
signal  flow  list  generator,  plus  a program  which  mechanized  a particular  bus  command 
and  control  mode!  that  was  initially  driven  by  the  synthetic  signal  flow  list.  Subsequently, 
the  program  was  modified  so  that  it  could  be  driven  either  by  the  synthetic  signal  flow 
list,  or  by  the  real  signal  flow  list  as  filtered  by  the  Utility  Subsystem.  A number  of 
versions  of  this  program  were  produced,  in  which  various  bus  control  models  were  tested, 
output  formats  developed,  etc.  The  program,  called  DASIM,  was  written  in  Fortran, 
and  it  comprised  about  1300  lines  of  source  code.  It  consisted  mainly  of  a three-stage 
sort/map  process,  as  illustrated  in  Figure  A-16. 

c . Dynamic  Subsystem 

The  "breadboard ing”  done  in  connection  with  the  Dynamic 
Subsystem  differed  from  the  other  efforts  in  that  it  was  mainly  an  evaluation  of  GASP, 
aimed  at  ensuring  its  suitability  as  a vehicle  for  implementation  of  MUXSIM  dynamic 
models.  As  has  been  noted  elsewhere,  MUXSIM  dynamic  models  are  discrete-event 
type  simulation  models  which  are  useful  in  determining  optimal  bus  commana  and  control 
disciplines,  optimal  multiplex  system  redundancy  management  schemes,  etc. 
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Figure  A-16.  DASIM  Flow  Chart 


A GASP  II  card  deck  (about  1500  cards)  was  obtained  -rom  the 
GAS;  deveiopers/supporters  (Pritsker  and  Associates),  and  made  operational  on  the 
Harris  DoracruN.  Although  GASP  !!  is  fortran-based,  a number  of  changes  were  requires, 
to  perform  the  above.  Thereafter,  GASP  !1  was  used  to  develop  and  run  several  models 
typical  of  the  simpler  MUXSIM  dynamic  models  that  were  anticipated.  These  exercises 
served  to  verify  that  GASP  II  was  an  appropriate  choice  for  implementation  of  MUXSIM 
Dvnamic  Subsystem,  because:  (1)  it  made  possible  rapid  development  of  dynamic  MUXSIM 
mode  ana  (2)  it  was  appropriate  for  use  on  a minicomputer  system. 

d.  Executive  Subsystem 

The  Executive  Subsystem  breadboard  served  mainly  to  clarify 
requirements  for  the  MUXSlM-user  interface,  and  to  develop  algorithms  for  its  imple- 
mentation. The  Executive  was  intended  to  be  interactive,  and  with  optional  tutorial 
arid  coaching  features.  Figure  A-17  and  A-'i8  show  some  examples  of  User-Executive 
dialogues  produced  by  this  breadboard,  it  was  programmed  in  Fortran,  and  about  1000 
lines  of  source  code  were  required. 

e . ASYSTD  Evaluation 

Although  it  was  concluded  in  the  MUXSIM  definition  phase  ihc 
certain  types  of  multiplex  system  designer  questions  are  best  handled  by  means  other  t; 
simulation,  it  is  true  that  simulators  now  exist  which  cover  areas  excluded  from  he  >cupe 
of  MUXSIM.  One  such  package  was  evaluated  as  part  of  the  Task  2 effort. 

The  package  evaluated  is  called  ASYSTD  (Advanced  Communi- 
cations System  Time  Domain  Techniques),  it  was  available  at  no  charge  from  NASA,  is 
written  in  Fortran  V for  the  Univac  1108,  and  consists  of  9133  source  ccrds.  ASYSiD  is 
a time  domain  simulation  program  which  provides  the  user  with  the  means  for  observing 
the  effects  which  a system  (cascade  of  model  elements)  may  have  on  a time-varying  input 
waveform.  Input  waveforms  or  driving  functions  may  be  square  waves,  transcendental 
functions,  or  special  functions  defined  by  table.  Model  elements  include  such  ccmmun  - 
cations  system  components  as  filters,  detectors,  etc.  Outputs  are  time-varying  voltage 
waveforms  which  may  be  presented  in  various  ways. 

it  was  concluded  that  there  was  no  immediate  application  tor 
ASYSTD  techniques  in  the  treatment  of  bus  traffic  handling  problems,  which  are  a primary 
focus  of  MUXSIM.  The  language  of  ASYSTD  was  founa  to  be  simple  and  efficient; 
ASYSTD  use  requires  only  a minimal  amount  of  code  from  the  user.  Finally,  :t  was 
found  that  ASYSTD  computer  runs  are  expensive,  ranging  from  $10  for  the  simplest  runs 
to  an  estimated  several  hundred  dollars  for  the  more  complex  models. 
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4. 


TASK  3 - FUNCTIONAL  DESIGN  SPECIFICATIONS 


The  final  task  in  the  MUXSIM  design  phase  was  to  produce  a detail  functional 
design  specification  for  MUXSIM.  This  was  done  in  accordance  with  the  outline  provided 
in  Figure  A-19.  The  original  specification  in  full  is  part  of  the  Second  Interim  Technical 
Report  (August  1974),  and  is  included  in  the  MUXSIM  System  Modification  Design  Data  Manual. 
The  specification  was  prepared  generally  according  to  the  outline,  except  that  subsystem  details 
were  provided  in  somewhat  unstructured  form  by  means  of  the  documentation  from  the  probe  coding 
or  software  breadboard  exercises. 

Task  3 was  executed  in  a straightforward  manner.  The  procedure  used  was 
to  select  a specification  format  compatible  with  existing  Air  Force  software  specification 
standards,  and  to  integrate  and  restructure  the  results  of  Task  2 so  as  to  fit  that  format. 

Some  time  was  saved  by  leaving  some  of  the  subsystem  details  in  unstructured  form,  as 
has  been  noted  above . 


SCOPE 


1 .1  Identification 
1 .2  Functional  Summary  of  MUXSIM 

1 .2.1  Executive  Subsystem 

1.2.2  Static  Subsystem 

i .2.3  Dynamic  Subsystem 

i .2.4  Utility  Subsystem 

APPLICABLE  DOCUMENTS 

2.1  Radiation  Documents 

2.2  GASP  Documents 

2 .3  DEC  Documents 

2.4  Other  Documents  (Military  Specs,  etc.) 

REQUIREMENTS 

• General  description  of  host  system  hardware  and  software 

• MUXSIM  interfaces  with  peripheral  equipment 

• MUXSIM  interfaces  with  other  programs 

• General  description  of  MUXSIM  functions 

3.1  MUXSIM  Definition 

• Requirements  imposed  by  interfaced  equipment 

• Requirements  imposed  by  other  interfaced  programs 

• Major  functions  of  MUXSIM 

Executive  subsystem 
Static  subsystem 
Dynamic  subsystem 
Utility  subsystem 


Figure  A-19.  MUXSIM  Functional  Design  Specification  Outline  (Sheet  I of  4) 
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3.2.1  Executive  subsystem 

3. 2. 1.1  Inputs 

3. 2. 1.2  Processing 

• Purpose 

® Approach 

• Diagrams 

3. 2. 1.3  Outputs 

3. 2. 1.4  Special  requirements 

3.2.2  Static  subsystem 

3. 2. 2.1  Inputs 

3. 2. 2. 2 Processing 

• Purpose 

• Approach 

• Diagrams 

3. 2. 2. 3 Outputs 

3. 2. 2. 4 Special  requirements 

3.2.3  Dynamic  subsystem 

3. 2. 3.1  Inputs 

3. 2. 3. 2 Processing 

• Purpose 

® Approach 

• Diagrams 

3. 2. 3. 3 Outputs 

3. 2. 3. 4 Special  requirements 
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3.2.4  Utility  subsystem 


3.2.4. 1 

3. 2.4.2 


Inputs 

Processing 


Purpose 

Approach 

Diagrams 


3. 2. 4. 3 Outputs 

3. 2. 4. 4 Special  requirements 


3.3  Adaptation  (Factors  associated  with  a different  choice  of  host  system 
or  operating  system  for  MUXSIM.  These  factors  affect 
scope  of  MUXSIM  operational  functions.) 


3.3.1 

General  environment 

3.3.2 

System  parameters 

(Constant  describing  maximum  number 
of  signals  in  SFL,  maximum  number 
of  terminals,  etc.) 

3.3.3 

System  capacities 

(Number  of  simultaneous  displays. 

host  system  core  and  mass  storage 
requirements,  etc.) 

QUALITY  ASSURANCE  PROVISIONS 


4.1  Introduction 


4.2  Development  Test  Requirements  (All  levels  except  acceptance  level) 

4.3  Acceptance  Test  Requirements 

4.4  Summary  of  Test  Program 

PREPARATION  FOR  DELIVERY  (N/A) 


Figure  A-19.  MUXSIM  Functional  Design  Specification  Outline 
(Sheet  3 of  4) 
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NOTES 

6 . 1 MUXSIM  size  estimates 

6 .2  MUXSIM  Specification  Process 

6 .3  Modular  Programming  Guidelines 

6 .4  Documentation  Requirements 

APPENDICES 

(Requirements  which  are  contractually  a part  of  the  specification  but  which 
for  convenience  of  specification  maintenance,  are  incorporated  herein) 

• Mathematical  derivations  (e.g.,  of  test  case  results) 

• Alternative  algorithms 

• Summary  of  equations 

• Definitions  of  terms 

• DAIS  Technical  Notes 

• B1  technical  documents 

• SFL  descriptions 


Figure  A-19.  MUXSIM  Functional  Design  Specification  Outline 
(Sheet  4 of  4) 
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SECTION  V 


SUMMARY  AND  CONCLUSIONS 


The  MUXSIM  development  plan,  covered  in  Section  II,  called  for  a three- 
phase  effort,  in  which  the  phases  were  MUXSIM  definition,  design,  and  implementation, 
respectively.  This  appendix  has  covered  the  definition  and  design  phases.  A separate 
appendix  is  devoted  to  the  implementation  phase. 

The  major  problem  solved  in  the  definition  phase  (covered  in  Section  II!) 
was  that  of  scoping;  i.e.,  what  was  MUXSiM  to  include,  what  to  exclude,  and  why. 

This  problem  was  simplified  by  the  assumption  (since  proven  invalid)  that  MUXSIM  was 
to  be  implemented  on  a DEC  PDP-1 1/45  minicomputer  system.  Another  useful  scoping 
device  was  a decision  to  focus  MUXSIM,  as  a multiplex  system  designer's  analysis  tool, 
on  those  significant  design  questions  fcr  which  answers  were  required  early  in  the  design 
process,  and  for  which  answers  could  not  be  conveniently  obtained  by  means  other  than 
simulation.  The  major  output  of  the  definition  phase  was  a set  of  MUXSIM  functional 
requirements,  covered  in  Section  III,  5. 

The  MUXSIM  design  phase,  covered  in  Section  IV,  was  done  in  a straight- 
forward three-step  process.  The  first  step  v/as  a functional  partition  of  MUXSIM  into 
four  independent  subsystems;  the  next,  a detail  functional  design  of  each  of  the  subsystems; 
and  the  last,  an  integration  of  the  four  detail  designs  into  a single  functional  design 
specification  per  applicable  military  software  specification  standards.  A probe  coding 
or  software  "breadboarding"  approach  was  used  in  the  second  step,  and  found  to  have  a 
number  of  advantages.  The  major  output  of  the  design  phase  was  the  MUXSIM  functional 
Design  Specification,  the  outline  for  which  is  given  in  Section  IV,  4. 


A conclusion  of  the  two-phase  effort  was  that  a cost-effective  MUXSIM 
could  be  functionally  defined,  and  that  a version  of  it  could  be  designed  so  as  to  be 
implementable  on  a DEC  PDF- 11/45  host  system.  The  evidence  for  this  conclusion  lies 
in  the  MUXSiM  functional  definition  and  the  MUXSIM  functional  design  specification, 
both  of  which  are  described  herein. 
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PRECEDING  PAdEi^LANK-NOT 


APPENDIX  B 

MUXSIM  IMPLEMENTATION 


/ 

FILMED 


PHASE  III  REPORT 


SECTION  I 


INTRODUCTION 


The  third  phase  of  Multiplex  Simulator  Design  Study  was  an  implementation 
of  the  basic  parts  of  the  Software  Simulator  which  were  conceived  in  phase  one  and  de- 
signed in  the  second  phase.  The  requirements  outlined  in  the  Statement  of  Work  for 
Phase  Three  were  for  the  construction  and  verification  of  a Simulator's  Main  Software 
Structure  and  a set  of  models  which  are  in  line  with  current-day  hardware  implementa- 
tion concepts  for  Avionics  Multiplex  Systems. 

The  object  of  the  implementation  was  to  prove  the  feasibility  and  usefulness 
of  such  a tool,  as  the  basis  for  development  of  concepts  for  more  sophisticated  practical 
multiplex  systems  and  as  the  basis  for  development  of  future,  more  refined  versions  of  the 
tool.  An  initial  evaluation  of  that  which  was  implemented  considers  the  simulator  as  a 
software  package  which  does  computer-aided  design  and  design  verification  of  digital  in- 
formation transfer/multiplex  system.  It  appears  to  be  a valuable  aid  for  an  organized 
approach atspecifying and  designing  multiplex  systems  for  diverse  applications. 

Two  obvious  advantages  are: 

• Quick-look  evaluations  of  different  systems  by  allowing  a man,  inter- 
acting with  a computer  terminal,  to  call  the  different  models  and  get 
rapid  quantitative  answers  which  are  derived  from  a fairly  sophisticated 
and  detailed  data  base  representation  of  his  problem,  thereby  greatly 
reducing  the  probability  of  a judgment  error  in  his  evaluation  of  the 
problem . 

• Low-cost  documentation  of  the  potential  system  selected  down  to  the 
pin  assignment  level  for  use  in  system  and  subsystem  specifications  and 
documentation. 

The  scope  of  the  implementation  effort  was  to  build  the  basic  framework  and 
implement  three  of  the  eight  static  and  one  of  the  two  dynamic  models  which  were  de- 
fined during  the  MUXSIM  design  phase.  The  models  were  defined  as  representative  of 
the  current  hardware  implementation  philosophy  and  are  considered  typical  of  those  with 
which  MUXSIM  needs  to  cope.  In  retrospect,  the  framework  implemented  makes  model 
construction  easy;  therefore,  all  ten  models  were  implemented  instead  of  the  four  which 
were  planned.  It  turned  out  to  be  a minimal  effort  to  implement  the  additional  static 
models. 


101 


- +1 


SECTION  II 

HISTORY  OF  IMPLEMENTATION 


i 


i 


The  Implementation  Phase  was  initiated  immediately  after  the  Design 
Phase.  Since  the  implementation  was  conducted  by  the  team  that  had  conducted  the 
Conceptual  and  Design  effort,  it  was  handled  more  as  an  extension  to  the  prior 
effort,  thereby  facilitating  a larger  interplay  between  the  results  of  the  prior  efforts 
and  the  findings  of  this  phase. 

Some  major  concepts  were  streamlined,  particularly  the  data  base  hand- 
off  between  the  software  subsystems.  The  basic  time  frame  of  this  effort  was  July 
1974  through  October  1975.  The  final  acceptance  test  was  conducted  in  June  1976. 

The  Implementation  effort  was  handled  in  three  parts,  as  with  many 
other  major  software  system  implementation  efforts: 

(1 ) Software  System  Design 

(2)  Software  Program  Design,  Implementation  and 
Verification 

(3)  System  Integration  and  Verification 

However,  the  effort  was  impacted  by  the  unavailability  of  the  intended 
host  system,  an  AFAL  PDP-11,  some  unanticipated  difficulties  in  using  the  operating 
system  RSX-11D,  and  the  unavailability  of  host  system  support  personnel.  A solution 
was  generated  to  allow  use  of  AFAL's  DEC  System-10  as  the  host  system.  This 
change  caused  a program  disruption  which  resulted  in  a temporary  implementation 
phase  effort  reset.  In  an  effort  to  minimize  cost  impact,  parts  of  the  Software 
System  Design  were  left  the  same,  since  the  DEC  System-10  can  execute  PDF-11 
software  without  major  penalties  in  time  of  execution. 

The  actual  partition  between  the  design  effort  and  the  implementation 
effort  was  not  cleanly  divided.  The  design  effort  was  carried  forward  and  reflected 
somewhat  in  the  first  implementation  task,  the  Software  System  design. 

Also,  a probe-coding  effort  had  been  conducted  during  the  design 
phase.  The  main  requirements  which  instigated  this  probe-coding  effort  were: 
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• Establishment  of  the  physical  size  for  MUXSIM,  since  the 
intended  host  system  was  o PDP- 11/45  minicomputer  which 
has  limited  capability.  It  was  considered  a risk  and  action 
was  therefore  required  to  assert  that  this  effort  would  be 
feasible  while  using  that  host  system. 

• Establishment  of  some  degree  of  confidence  in  the  feasi- 
bility of  the  functional  (user)  and  logical  (software) 
requirements  of  the  various  subsystems.  It  was  felt  that 
some  growth  in  experience  was  necessary  to  establish  a 
working  system  definition. 

• Establishment  of  the  best  possible  functional,  logical,  and 
physical  parameters  description  for  inclusion  in  the  MUXSIM 
System  Specification. 

The  result  of  this  probe-coding  effort  was  an  understanding  of  the  trans- 
lation of  the  user  requirements  to  software  requirements.  It  also  helped  jell  and  narrow 
the  scope  of  MUXSIM  implementation  to  a feasible  and  usable  tool. 

Another  result  which  did  not  become  apparent  to  the  MUXSIM  team 
until  later  in  the  implementation  phase  was  that  the  probe-coding  effort  served  as 
a software  breadboard  and  therefore  the  emerging  system  was  more  polished  and  re- 
fined than  was  anticipated.  Attesting  to  this  was  the  fact  that  the  physical  descrip- 
tion parameters  (lines  of  code)  projected  as  a result  of  the  probe-coding  effort  were 
almost  twice  those  actually  required;  what'was  accomplished  was  a larger  task  than 
had  originally  been  scoped. 

The  two  major  divisions  of  the  task  were  planned  and  executed  as 
two  separate  entities.  They  are: 

• User  Ease  Software 

• Operation  Software 

An  interface  requirement  was  established  between  these  two  efforts  early  in  tne 
game,  modified  once  when  the  change  to  DEC  System-10  came  along,  and  then 
not  disturbed  until  the  integration  effort  when  the  concept  was  finalized. 

The  integration  effort  was  carried  forward  in  two  basic  steps.  An 
effort  to  marry  one  of  the  programs  from  the  Operation  Software  was  pursued  early 
in  the  program  to  verify  the  integration  approach.  The  bulk  of  this  effort  was 
expended  toward  the  conclusion  of  the  program,  prior  to  final  System  Test. 
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Since  the  Operation  Software  is  run  progrom-fcy-program  in  pseudo- 
oaten,  the  verification  task  of  the  individual  program  went  a iong  way  in  aiding 
fhe  verification  of  the  system  performance.  Pseudo-batch  in  th u sense  means  that, 
even  after  the  system  is  integrated,  the  programs  still  function  basically  as  a separate 
entity.  This  is  attributed  to  the  requirement  for  modularity  which  resuited  in  the 
programs  being  functionally  isolated. 

The  functional  requirements  of  this  particular  System,  and  for  that 
rrattei  "he  Subsysrems  themselves,  were  such  that  the  logical  construction 

of  modules  lends  itrelf  to  a progressive  operation  on  the  data  base,  where  the 
end  result  of  each  modular  step  has  significance  to  the  user.  For  example,  the 
Signal  List  (Data  base)  is  mapped  in  remotely  located  terminals  (remote  terminal 
assignment).  The  output  of  this  program  is  useful  because  it  shows  the  designer 
t'.o  signal  handling  requirements  for  the  remote  terminal.  The  signals  per  terminal 
are  then  assigned  to  data  words,  and  words  are  assigned  to  messages.  Each  one  of 
these  steps  bears  useful  results  because  it  gives  the  designer  further  system  specifica- 
ion  for  his  terminal  design.  These  governing  requirements  presented  the  logical 
break  points  for  the  modular  construction. 

This  effort,  however,  also  set  forth  a requirement  for  progressive 
inter-program  hand-off,  which  was  best  handled  by  a lower-level  effort,  longer 
time-frame  program  than  was  perhaps  originclly  anticipated.  In  this  way,  the  pro- 
grams which  were  developed  avoided  expenditures  of  debugging  awkward  inter- 
program interfaces  during  the  integration  effort. 

Five  field  trips  were  required  Curing  the  DEC  System-iO  program. 

(Two  earlier  trips  were  conducted  on  the  PD?-)  l/45  effort).  The  first  DEC 
System-10  trip  was  primarily  a facility  familiarization  trip  and  served  as  an  intro- 
auction  between  Harris  personnel  end  AFAL  and  AFAL  support  contractor  personnel. 
However,  since  a considerable  effort  had  already  transpired,  the  following  soft- 
were  wes  verified: 

1 . GASP  IV  Subroutine  Librcry 

2.  User  Interactive  and  Executive  Subsystem  Concepts 

3.  Utility  Subsystem 

4.  Static  Subsystem  Programs  which  had  been  coded  at 
the  time  of  that  trip. 

5.  Use  of  DEC  Editing  System 

Also  verified  were  the  use  of  the  portable  remote  telephone  access  terminal  (T! 
Silent  700)  and  tape  compatibility  between  Harris'  facility  and  AFAL's  system. 
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All  programs  were  left  resident  in  source  file  in  the  system,  and  could  be  edited 
and/or  executed  by  means  of  the  remote  terminal. 

During  the  remainder  of  the  software  program  design  and  verifica- 
tion, the  remaining  MUXSIM  programs  were  built  and  debugged  on  the  Harris 
facility.  After  a set  of  programs  had  been  completed,  they  were  modified  for 
the  DEC  System-10.  This  set  was  then  shipped  to  AFAL,  where  it  was  installed 
on  MUXSiM's  assigned  Disk  Storage  area  in  a source  file  by  AFAL  personnel. 
Harris  personnel  then  proceeded  to  access  these  programs  from  Melbourne  via 
the  Remote  Terminal  and  to  direct  successful  compilation  and  execution  of  each 
program.  This  approach  saved  considerable  travel  and  time  in  program  debug 
and  installation  on  the  DEC  System-10. 

The  initial  system  integration  effort  was  also  conducted  remotely 
via  this  interface.  The  second,  third,  and  fourth  DEC  System-10  trips  were 
conducted  at  the  finalization  of  the  system  integration  effort.  During  this 
period  the  DEC  System- 10  was  being  upgraded  to  a dual  CPU  System.  This 
resulted  in  a slightly  longer  integration  effort,  due  to  the  DEC  System-10 
trcnsitory  nature.  All  programs  were  reverified  and  then  integrated  into  the 
system.  These  trips  also  served  as  an  initial  debug  of  the  User  Manual  and  the 
actual  system  operational  concept. 

The  fifth  trip  was  for  the  purpose  of  final  Acceptance  test.  This 
was  the  system  demonstration  and  sell-off  effort.  The  MUXSIM  System  Test 
Plan  (Reference  10)  contains  the  Acceptance  Test  Procedure  which  was  used  for 
this  effort. 
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SECTION  III 

REQUIREMENTS  .-OR  IMPLEMENTATION 

1 

The  contractual  requirements  evoked  on  Harris  Electronic  Systems  Division 
durinq  th  • nplementation  phase  were  to  provide  the  personnel,  materials  and  facilities  to 
impt err. er  he  multiplex  simulator  system  design.  The  overall  program  entailed  the  prep- 
aration rt  i,ia  jduai  Drograrn  modules,  the  integration  of  these  modules  into  a simulator 
orient  ana  demon  -ration  of  .He  system.  Specifically  the  requirements  are  as  listed  below: 

d 

Tc  de/olop  and  implement  the  detailed  program  modules  from  the  system 
design  accomplished  under  the  prior  phases.  The  modules  were  to  be 
coded,  debugged,  and  tested  for  use  on  the  DEC  Sy:.em-10  (originally 

PDP  11/45).~ 

To  integrate  the  individual  modules  into  a simulator  system.  The  system 
was  to  be  tested  to  prove  that  the  modules  function  together  as  a system. 

© 

To  develop  a test  plan  for  each  of  the  modules  and  for  the  overall  sys- 
tem The  test  plan  was  to  detail  the  exact  steps  to  be  performed  in 
order  to  prove  that  the  modules  and  system  are  operating  correctly. 

To  demonstrate  that  the  simulator  works  as  specified . This  demo 

was  to  be  on  the  DEC  System-10  computer  located  in  the  Air  Force 
Avionics  Laboratory.  The  contractor  was  ro  integrate  the  simulator  on 
the  DEC  System- 10.  The  demonstration  was  to  inc!ude  the  analysis  c1 
a proposed  or  working  multiplex  system. 

Additional  requirements  are  extracted  from  the  efforts  of  tfm  prior  Defir  e aH 
Design  phases.  They  are  categorized  into  the  following  three  divisions: 

Functional  - those  requirements  which  are  specified  from  the  user's  poi  it 
of  view. 

w 

[ tj 

© 

Logical  - those  requirements  v/hich  are  specified  from  the  orogramrrm  s 

point  of  view.  1 

1 1 

'« 

• 

Ph/sical  - those  requirements  which  are  specified  from  the  computer 
operator's  point  of  view. 

L *»  f 

V 

k 

With  the  above  definitions  in  mind,  the  prime  functional  or  user  requirement 
of  the  simulator  implementation  phase  was  to  construct  a software  simulation  system,  as 

^.ior  defined  and  designed,  which  would  be:  j 

& 

a 

(1) 

easily  modified  and  expanded  to  answer  system-level  questions  generat  d 
by  *he  dynamic  environment  of  the  multiplex  world. 

C 

i > 

r •.  • 

« 
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(2)  effectively  used  in  the  early  stages  of  a hardware  design  and  develop- 
ment project. 


(3)  detailed  enough  to  provide  continuing  value  throughout  the  hardware 
project  evolvement,  particularly  during  the  evaluation  of  system 
redesign  requirements. 

(4)  easily  learned  and  comprehended  by  people  who  need  the  tool,  and 
doesn't  require  a highly  trained  software  simulation  specialist  to  use 
the  tool  effectively. 

Two  different  additional  functional  requirements  became  apparent  at  the 
outset  of  the  implementation  effort.  They  are: 

(1)  requirement  for  a more  text-oriented  output,  formatted  in  a more 
readable  presentation. 

(2)  a requirement  which  called  for  a family  of  outputs,  such  as  a text- 
oriented  signal  flow  summary,  formatting  of  bus  messages,  etc. 


At  the  outset,  the  MUXSIM  team  had  anticipated  using  only  the  bus  traffic 
requirements  data  required  by  the  signal  flow  summaries  and  which  was  hand-extracted 
from  the  signal  list.  It  was,  therefore,  deemed  necessary  to  expand  the  input  require- 
ments at  this  time  for  all  signal  data,  including  dictionaries  which  would  provide  the 
user  with  added  text.  This  expanded  input  was  necessary  for  the  creation  of  user-read- 
able formats  for  the  various  outputs.  Another  factor  which  was  weighed  at  the  time  of 
initial  implementation  was  the  fact  that  planning  and  implementing  some  of  this  approach 
early,  would  result  in  a minimum  impact  to  the  overall  program  and  enhance  MUXSIM's 
usage.  Therefore,  this  effort  was  factored  in  during  this  system  implementation  effort. 

The  following  logical  (programming)  requirements  were  working  constraints 
during  the  implementation  phase: 

(1)  Software  system  transportability  or  machine-independence  requirement. 
It  had  been  specified  that  MUXSIM  should  enjoy  a relatively  high  de- 
gree of  machine-independence. 

(2)  Highly  modular  system  which  lends  itself  to  easier  construction  and 
verification.  It  was  desirable  that  the  modules  be  functional  in 
nature  to  enhance  program  modification. 

(3)  FORTRAN  IV  to  be  the  programming  language.  GASP  IV  (General 
Activity  Simulation  Program)^' ^ was  to  be  used  for  dynamic  simulation. 


^GASP  IV  Subroutine  library  can  be  purchased  from  Pritsker  and  Associates,  Inc.', 
West  Lafayette,  Indiana. 

^Pritsker,  A.A.B.,  The  GASP  Simulation  Language,  John  Wiley  & Sons,  Inc., 
New  York,  1974. 
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(4)  The  system  to  operate  interactively  for  ease  of  operation, with  optional 
coaching  features  to  facilitate  learning  ;he  system. 

(5)  The  following  subsystem  partitioning 

♦ EXECUTIVE  Subsystem 

* UTILITY  Subsystem 
« SiATlC  Suosystem 

• D'/NAMIC  Subsystem 

The  following  physical  requirements  were  evoked: 

(1)  Fez  economy  in  development,  the  modules  (program)  were  to  be  coded, 
debugged,  and  tested  on  Harris'  DPL  (Datacraft  6024/5)  machine  prior 
to  installation  on  AFAL's  system. 

(2)  AFAL's  Fiost  System  to  be  a DEC  System-10.  Originally  the  intended 
host  system  was  a PDP  1 i/45. 

With  these  requirements  the  team  proceeded  into  the  first  effort,  the  design 
of  the  Software  System.  The  resulting  goal  of  the  simulation  software  design  effort  was 
a set  of  modular  programs  which  could  be  constructed  and  verified  independent  of  othe 
modules.  One  restriction  evolved  as  a result  of  this  partition.  That  is,  most  of  the  or 
grams  defined  were  sequential  in  nature;  the  output  of  the  prior  program  become'-  th 
input  for  the  preceding  program.  The  programming  effort  was  best  handled  sequerAalc 
rather  than  in  a parallel  effort  tc  avoid  integration  problems  caused  by  awkward  inter- 
faces resulting  from  early  definition,  it  proved  to  oe  best  solved  by  the  program  actuai 
iow  manpower  expanded  time  effort 

The  design  phase  defined  eight  static  models  and  two  dynamic  models,  ihe 
static  models  were  defined  ro  handle  oil  the  signal  grouping  ana’  assignments  which  ore 
representative  of  MUX  hardware  implementation  grouping  of  signals.  The  siatic  subsys- 
tem in  general  handles  those  computations  associated  with  non-variant  periodic  transfer 
of  information.  The  dynamic  models  handle  those  computations  associated  with  stochastic 
time  variant  transfer  of  information.  The  dynamic  models  also  can  take  into  account  rhe 
effects  of  the  non-variant  periodic  transfer. 


Of  the  eight  static  models  defined,  the  effort  originally  was  scaped  to  do 
three  models:  SA,  SB  and  SE.  The  eight  static  models  are: 


Model  Name 

SA 

SB 

SC 

SD 


STATIC  MUX  MODELS 
Information  Transfer  Discipline 
T/T  Transfer 

T/C/T  transfer  (bit  shuffling) 
Digital  T/T,  Discrete  T/C/T 
Hybrid  Transfer 


109 


Model  Name 


Information  Transfer  Discipline 


SE  T/T  Transfer  with  BCIU  Broadcast  Reception 

SF  T/C/T  Transfer  with  BCIU  Broadcast  Reception 

SG  Hybrid  Transfer  with  BCIU  Broadcast  Reception 

SH  T/C/T  Transfer  (word  shuffling) 

Of  the  two  dynamic  models  defined,  only  one  was  scoped  for  this  effort 
(Model  DA).  The  two  dynamic  models  are; 

DYNAMIC  MUX  MODELS 


Model  Name 
DA 

DB 


Description 

Model  of  MUX  system  using  demand-access 
information  transfer  disciplines. 

Model  of  MUX  command-response  informa- 
tion transfer  disciplines,  incorporating 
consideration  of  redundancy  and  fault- 
handling schemes. 


After  the  MUXSIM  main  software  structure  was  implemented  it  was  determined 
that  the  additional  Static  Model  construction  was  easier  than  anticipated,so  all  eight 
models  were  implemented.  Both  dynamic  models  were  also  implemented  as  agreed  to  on 
the  Test  Plan. 


110 


c\_ 


SECTION  IV 


MUXSIM  CONSTRUCTION 


1. 


INTRODUCTION 


in  oraer  to  adequately  explain  the  construction  of  the  MUXSIM  system 
software  '.tore,  it  must  be  viewed  from  the  functional  (user),  logical  (programmer), 
aid  ohysicui  (computer  opera  ror)  points  of  view . Functionally,  the  points  of  v-ew  ere: 
"What  is  it  for  and  hcv  is  it  used?"  Logically,  it  is  structured  into  two  parts:  that  software 
which  de  ;/es  >he  desired  results  and  thai  software  which  is  frr  user  ecse  or  convenience, 
hys ’colly,  it  is  viewed  from:  How  it  runs,  storage  size,  time  for  program  execution, 
inner  requirements  and  output  requirements. 

The  following  two  notes  should  be  made  of  the  specific  simulator  construction 
aevf  loped  during  this  implementation  phase: 

e The  interrelationship  between  the  static  and  dynamic  was  not  better 
explored  because  of  lack  of  realistic  data  base,which  contains  the 
parameters  defining  the  signalling  requirements  stochastically. 

« The  present  hardware  implementation  concepts  projected  the  reiat'an 
ship  implemented.  However,  as  new  hardware  concepts  develop  and 
consequently  new  models  are  generated,  this  relationship  could  chcnge. 
The  programs  are  modular  and  ns  long  as  interface  requirements  ore 
respected  they  can  easily  be  directly  replaced  with  new  ores  or  new 
programs  can  be  inserted  be  .ween  existing  ones. 


2. 


FUNCTIONAL  CONSTRUCTIONS 


The  functional  or  user  view  of  the  system  is  best  described  by  surveying  the 
system  from  two  distinct  vantage  points  posea  by  the  following  two  questions: 

« What  is  MUXSIM  used  for? 


o How  is  MUXSIM  applied? 

| he  first  question  is  answered  by  a brief  description  of  the  system's  manipulation  of  the 
different  pertinent  users'  parameters.  The  second  question  is  treated  by  a description  or 
a .ypical  user's  scenario . The  prime  object  of  both  of  these  discussions  is  to  present  a 
useful  overview.  For  interested  personnel, the  details  of  operation  are  covered  in  the 
MUXSIM  User's  Manual  and  MUXSIM  System  Modification  Design  uo  re  Manual. 


m 


a. 


What  is  MUXSIM  Used  For? 


This  MUXSIM  implementation  effort  was  developed  to  address  the 
design  and  design  verification  of  digital  data  systems  used  for  handling  intra -aircraft 
information.  It  addresses  any  of  a family  of  aircraft  data  transfer  requirements  where 
information  originating  from  many  sources,  spatially  separated,  must  be  transferred  and/or 
processed,  then  retransferred  to  an  equally  complex  destination  arrangement.  The  imple- 
mentation is  general  in  nature  so  that  MUXSIM  can  be  used  for  diverse  applications  where 
the  above  problem  exists. 

Essentially,  the  MUXSIM  programs  serve  to  link  the  gap  between 
detailed  analysis  and  prototype  hardware.  It  provides  a means  of  interplaying  the  pieces 
of  the  detailed  analysis  (such  as  update  rate  requirements,  sampling  requirements,  data 
buffering  requirements,  bus  data  rate  requirements,  processing  delay  requirements)  from 
a myriad  of  point-to-point  signalling  into  a coherent  requirement  which  can  be  verified 
for  compatible  performance  by  a computer  prior  to  attempting  a hardware  development 
program,  thereby  preventing  costly  system  errors  from  being  implemented  in  hardware. 

For  this  reason  the  cost  effectiveness  of  the  simulator  depends  on  its  earliest  use  in  the 
design  or  modification  cycle. 

The  following  is  postulated  as  an  example  of  the  use  of  MUXSIM 
during  a hardware  development  program. 

• In  the  conceptual  stages,  past  data  bases  developed  by 
MUXSIM  for  similar  systems  are  useful  for  bounding  the 
requirements. 

• As  the  development  program  matures,  MUXSIM  uses  the 
emerging  information  to  help  develop  the  peculiar  system's 
actual  data  handling  requirements. 

• As  candidate  systems  are  selected,  they  are  evaluated  to 
indicate  specific  relative meritsand  problems  of  each. 

A final  selection  is  based  on  how  these  advantages  and 
problems  affect  the  application. 

The  basic  operation  tasks  to  accomplish  the  above  were  defined 
during  the  prior  conceptual  and  design  phases  of  MUXSIM  and  were  divided  as  follows: 

• Data  base  management  and  accounting  task 

• Signal  information  grouping  and  handling  task  (representative 
of  hardware  implementation  requirements  such  as  remote 
terminal  assignment,  message  assignment,  bus  schedule,  etc.) 
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* Dynamic  simulation  o f data  translei  and  pro  ci  ssing 
requirements  task  to  derive  time  delay  statistics,  data 
buffering  requirements  ana1  other  potential  dare  queueing 
problems . 

From  riiose  three  operation  tasks  the  MIJXSIM  software  structure 
of  foi  r (three  opera. ion  r'u  • ne  user  ease)  subsystems  emerged.  fhey  were  also  defined 
duri  u,  'he  e ign  phase ,cac:  their  areas  of  responsibility  are  as  follows: 

ft  The  Utiiiry  Subsystem  manages  the  Signci  Fiow  Gist  and 

extracts  the  simulator  inputs  frorr  it.  Iv  uses  rhe  informatio' 
from  the  Signal  Flow  List  to  check  the  Equipment  Complement 
for  completeness,  flagging  any  equipment  and  signal  deficien- 
cies . 

» The  Static  Subsystem  handies  all  the  signal  information 
grouping  and  handling  such  as  Remote  Terminal  (RT  MAP) 
loading  task.,  the  data  bus  word  structuring  (WORD  MAP), 
the  data  bus  message  structuring  (MESSAGE  MAP),  as  well 
as  the  fixed-telemetry  format  message  structure  and  average 
bus  loading  and  utilization  computations. 

« The  Dynamic  Subsystem  handles  the  random  message 
scheduling  tasks  and  computes  the  dynamic  bus  load  me 
(queueing)  and  time  statistics . This  to  ! is  made  possible 
by  using  GASP  IV  (General  Activity  Simulation  Program) 
subroutine  lib, ary,  a powerful,  widely  used,  and  wed 
documented  simulation  package  which  is  commercially 
available. 

o The  Executive  Subsystem  (User  Ease  Soft-ware)  permits 
operation  from  a CRT  or  TTY  terminal  (console)  ar-d  has 
an  interactive  section,  with  optional  coaching,  'o  aid 
the  user  and  facilitate  learning  the  simulator  operations. 

Figure  3-1  depicts  the  above  MUXSSM  subsystem  mouuiar  softs  ere 
structure  and  its  interrelationships. 

Functionally  the  three  operation  subsystems  are  sequenced  as 
shown  in  Figure  B-2  when  a problem  is  being  worked  from  start  to  end.  ir  is,  howevc  , 
anticipated  that  other  iterations  will  be  useful  in  different  circumstances . f or  instar  ce, 
once  the  Signal  Flow  Summary  is  derived  from  a fixed  Signal  List-Data  Base  . t is  specu  ait. 
f-hn*-  rhe  Utility  Subsystem  would  be  bypassed  when  simuiot-ng  ctr w Remo:'  fermirai 
Configurations  or  running  different  Static  Models.)  The  Functional  re quirerre  Is  are, 
however,  more  adequately  described  using  the  sequence  shown  ir  Figur  i-  ' 
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Figure  B-l.  MUXSIM  Modular  Software  Structure 
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MUXSIM  System  Data  Flow  Diagram 
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At  the  start  of  the  sequence,  the  Utility  Subsystem's  bag  of  programs 
assists  the  MUXSIM  user  in  creating  an  accurate  workload  definition  (a  signal  list  which 
defines  the  information  transfer/processing  requirements)  for  the  aircraft  system  which  is 
being  evaluated.  This  effort  is  carried  forth  basically  as  depicted  in  Figure  B-3.  The 
first  task  consists  of  inputting  the  signal  list  and  compacting  it  to  minimize  data  storage. 

This  is  accomplished  by  extracting  dictionaries  from  some  of  the  signal  list  fields.  After 
that,  the  next  task  is  done  by  using  a Signal  Group  LRU  Assignment  Dictionary.  It  consists 
of  creating  a Signal  Flow  Summary  (SFS)  listing  extraneous  signals  contained  in  each 
subsystem's  list  and  which  are  not  related  to  that  hardware  subsystem.  The  succeeding 
task  consists  of  comparing  the  complementing  SFS  input/output  records  and  listing  those 
signal  summaries  which  don't  have  a matching  pair  in  the  complementary  list.  The  user 
can  then  employ  these  discrepancy  lists  to  either  update  and/or  correct  his  original  inputs 
and  then  reiterate  the  process  or  use  his  signal  list  edit  program  and  correct  the  signal 
list  file  on-line.  The  user  will  iterate  this  process  until  he  eliminates  all  incompatibilities 
in  the  signal  list  and  signal  flow  summary  or  is  contented  that  the  information  is  acceptable. 
The  corrected  signal  list,  either  in  its  original  input  or  recreated  from  the  summary  file 
to  remove  double  entries,  can  be  outputted  to  tape  and  added  to  the  workload  library 
which  serves  to  define  this  workload  for  historic  or  future  purposes.  It  is  also  used  as  a 
source  of  information  for  construction  of  other  workloads.  This  subsystem  has  the  capability 
of  modifying  the  LRU  designators  on  his  signal  list  to  generate  a modified  signal  list  repre- 
senting a different  system. 

Once  the  workload  (Signal  List)  data  base  has  been  satisfactorily 
cleaned  up,the  flow  proceeds  to  the  Static  Subsystem  as  shown  in  Figure  B-2.  The  Static 
Subsystem  consists  of  a set  of  operations,  groupings,  or  transformations  which  the  signals 
go  through.  This  is  representative  of: 

• grouping  the  signals  into  remote  terminals 

• grouping  the  signals  within  the  remote  terminal  into  words 

• grouping  words  into  messages  or  other  such  requirements 

For  the  models  implemented  in  this  effort, the  above  three  steps  were  considered  represen- 
tative and  were  so  modeled. 

As  per  Figure  B-2,  the  remote  terminal  assignment  is  the  first  effort 
of  the  Static  Subsystem.  This  effort  is  executed  as  depicted  in  Figure  B-4.  The  first  task 
in  this  Remote  Terminal  Assignment  Dictionary  locates  the  different  pieces  of  equip- 
ment (LRU's)  in  different  areas  of  the  aircraft  (i.e.,  bays,  etc.).  Thereby  each  signal 
is  in  essence  catalogued  by  location.  This  signal  information  is  totaled  by  signal  types 
(input  or  output  and  generic-analog,  discrete,  - category)  for  each  location  or  bay  and 
Remote  Terminals  previously  assigned  by  remote  terminal.  This  information  is 
reviewed  and  evaluated  by  the  user.  If  the  remote  terminal  assignment  is  not  satisfactory, 
the  user  assigns  or  reassigns  the  remote  terminals  through  a manual  update  of  the  LRU 
location  and  Remote  Terminal  Assignment  Dictionary.  The  process  is  reiterated  until  the 
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Static  Subsystem  RT  Assign  Task  Data  Flow  Logic  Diagram 


user  is  satisfied  that  he  has  the  desired  assignment  achievable  by  this  method.  If  fine 
tuning  of  signal-to-remote  terminal  assignment  is  considered  aesirable  then  the  last  step 
in  the  assignment  process  is  the  use  of  the  signal  flow  summary  edit  which  cl  lows  the 
user  to  interactively  move  the  signals  from  one  remote  terminal  to  another  (e.g.  if  only 
a few  analog  signals  are  present  in  a given  bay,  it  may  prove  helpful  if  they  are  all 
processed  by  the  some  RT).  This  new  assignment  is  totaled  and  evaluated  and  the  process 
is  reiterated  until  the  user  is  satisfied.  At  that  point  the  user  calls  the  documentation 
program  and  documents  his  configuration. 

Once  the  remote  terminal  assignment  is  complete,  the  data  bus 
message  is  formatted  in  a modular  sequence.  As  shown  in  Figure  B-2,the  first  step  consists 
of  mapping  the  signals  to  words  o'-  bytes.  This  is  done  by  a model-peculiar  mapping  algo- 
rithm which  is  used  by  MUX5IM.  The  specific  parameter  definitions  are  accomplished 
through  the  use  of  the  Data-Rate  and  Signal  Mapping  Algorithm  Dictionary. 

The  next  step  consists  of  mapping  the  words  or  bytes  to  messages. 
Again,  this  is  done  by  model-peculiar  mapping  algorithms  assisted  by  user  parameter 
definitions  of  the  particular  command  and  control  data  overhead  requirements.  Then  a 
computation  of  average  bus  traffic  is  accomplished  for  the  fixed  telemetry  format  traffic. 

The  last  step  represents  a three-way  mode  of  operation.  If  the 
information  transfer  discipline  depicted  by  the  data  base  is  of  the  fixed  telemetry  former 
variety ,then  the  fixed  format  scheduler  of  the  static  subsystem  is  a candidate  operaficr. . 

It  interleaves  and  schedules  the  transmission  of  messages  among  the  fundamental  update 
intervals  while  maintaining  the  required  transmission  periodicity  for  the  individual  message. 
In  essence,  this  task  consists  of  mapping  the  messages  into  sequence  (each  sequence 
represents  a group  of  messages  which  are  transmitted  in  a contiguous  sequence  on  the  bus). 
These  groups  are  then  fitted  into  the  schedule.  If  the  data  base  contains  only  fixed  telem- 
etry format  data,then  this  '■ask  could  conclude  the  operation. 

If,  however,  the  data  base  specifies  sporadic  transmission  require- 
ments for  the  signals,then  the  dynamic  subsystem  assists  the  user  in  the  task  of  determining 
the  additional  time  delay  and/or  message  queueing  statistics  for  his  hardware  system. 

Should  the  data  base  contain  only  sporadic  data  transmission 
specifications,then  the  last  step  could  consist  of  using  the  dynamic  subsystem  to  obtain 
additional  data-bus  loading  information. 

MUXSIM  provides  detailed  documentation  for  the  following  bus 
data  variables  (see  Figure  B— 2 ): 

• Corrected  equipment  list,  signal  list  and  signal  summaries. 

• The  signal-to-remote  terminal  assignment  (down  to  oin  level). 
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• The  signal -to-message  assignment  (down  to  signal  level). 

• Average  bus  utilization. 

• Message  scheduling  by  fundamental  update  interval  and 
individual  loading  and  utilization. 

• Time  delay  and  message  queueing  statistics. 

The  following  eight  static  models  were  implemented  as  part  of  the 
static  subsystem  and  are  available  for  use  as  part  of  the  signai-to-word-to-message  map- 
ping operation . 

Model  SA  - T/T  Transfer 
— 

This  model  is  representative  of  direct  transfer  of  information  from 
one  remote  terminal  to  another  remote  terminal.  The  information  is  grouped  into  messages 
which  are  separated  by  the  following  three  data  variables:  update  rate,  originating  ter- 
minal,and  destination  terminal . In  addition  there  is  a restriction  to  number  of  data  bus 
words  that  can  be  grouped  together  into  one  message.  This  quantity  is  a user  input.  The 
operation  prior  to  message  construction  was  the  data  bus  word  construction.  In  addition 
to  the  three  message  separation  variables,  the  data  word  construction  was  kept  separate 
by  signal  type  (generic  categories  - discrete,  analog,  etc.)  because  signal  conversion 
equipment  is  different  for  different  signal  types  and  word  groupings  would  be  separated 
from  equipment  to  equipment.  It  should  be  noted  that  these  functions  are  representative 
of  hardware  implementation  and  that  the  actual  hardware  implementation  approach  dic- 
tates the  model . 

Another  factor  which  is  considered  is  that  any  signal  whose  origin 
and  destination  is  between  the  same  Remote  Terminals  was  considered  to  be  c candidate 
for  dedicated  hardwiring  and  was  consequently  ignored  by  the  model. 

The  signal-to-worri  mapping  is  done  in  three  categories.  They  are: 
Category  A - Multisignal  to  Uniwords 
Category  B - Unisignal  to  Uniworas 

Category  C - Unisignal  to  Multiwords 

The  model  specific  information  is  inputted  via  the  Data  Rate  and 
Signal  Mapping  Algorithm  Dictionary. 
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Model  SB  - T/C/T  Transfer 


This  model  is  representative  of  a system  where  the  signoi  informc- 
tion  is  gathered  into  the  Central  Bus  Controlling  Unit,reformatted,  and  distributed.  The 
big  difference  between  Model  SB  and  Model  SA  is  that  most  data  is  transmitted  on  the 
bus  twice.  Therefore,  the  basic  approach  is  to  bring  the  signal  list  word  into  the  model 
twice.  The  first  lime  the  destination  remote  terminal  is  modified  to  central  unit  repre- 
sentation. The  second  time  the  origin  remote  terminal  is  modified  to  central  unit  repre- 
sentation, in  add:t'on  to  the  dedicated  hardwire  considerations  of  Model  SA,  the  signc's 
which  show  up  with  central  representations  for  origin  and  destination  are  considered  to 
an  interna!  manipulation  of  the  central  unit  and  are  consequently  deleted  from  the  system. 


Model  SC  - Digital  T/T,  Discrete  T/C/T 


This  model  is  representative  of  direct  transfer  of  signals  which  b/ 
"h^mselves  constitute  one  or  more  words  (Category  B and  C)  and  the  gathering  and  dis- 
persing of  the  Central  Bus  Controller  of  the  multisignal  word  (Category  A)  signal  type. 

Ti  e message  overhead  words  are  different  for  the  two  information  transfer  disciplines, so 
the  two  message  types  are  differentiated  when  assigning  the  overhead  words.  Each  type 
is  accordingly  representative  of  Models  SA  and  SB. 

Model  SD  - Hybrid  Transfer 

This  model  is  representative  of  a combination  of  the  Model  SA 
and  SB  disciplines  where  an  effort  has  been  made  to  minimize  the  data  bus  loading  b 
selecting  for  each  of  the  update  rates  the  discipline  which  has  the  lower  data  bus  rare 
in  essence.  Model  SA  and  SB  are  called,  the  lower  data  rate  data  transfer  discipline 
is  determined  as  a function  of  update  rate,and  those  results  are  selected.  All  message 
number  information  is  renumbered  cfter  the  word  and  message  transmission  discipline 
structure  has  been  selected  for  each  update  rate. 


Mode!  SE  - T/T  Transfer  With  BCIU  Broadcast  Reception 

This  model  is  representative  of  the  system  where  certain  Bus 
Control  Interface  Units  (smart  terminals, in  essence)  are  capable  of  receiving  any  message 
going  to  the  Central  (active  BCIU)  Control  and  extracting  the  information  they  need 
from  it.  The  hardware  implementation  is  such  that  any  signal  going  to  any  of  the  ter- 
minal designated  BCIU  is  grouped  together.  The  information  transfer  discipline  is  remote 
terminal  to -remote  terminal,as  model  SA. 

Model  SF  - T/C/T  Transfer  With  BCIU  Broadcast  Reception 


This  model  is  also  identical  to  model  SE  with  the  exception  flict 
the  signal  transfer  discipline  is  representative  of  the  central  gathering  and  dispersing 
unit,  as  in  Model  SB . 
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Model  SG  - Hybrid  Transfer  With  BCIU  Broadcasting 


This  model  is  like  model  SB,with  model  SE  discipline  instead  of 
model  SA,and  model  SF  discipline  instead  of  model  SB. 

Model  SH  - T/C/T  Transfer  (Word  Shuffling) 


This  model  is  similar  to  model  SB.  The  difference  in  discipline  is 
that  the  multisignal  to  word  (Category  A)  signal  types  are  packaged  in  the  same  fashion 
as  they  were  in  terminal-to-terminal  discipline  by  model  SA  before  they  are  shipped  to 
central.  This  model  represents  a system  where  the  bit  packing  is  done  ana'  undone  at  the 
remote  stations  and  the  central  unit  merely  regroups  the  words  into  messages. 

The  following  two  dynamic  models  were  implemented  as  part  of  the 
Dynamic  Subsystem  and  are  available  to  use  for  the  dynamic  bus  queueing  utilization 
computations. 


Model  DA  - Demand  Access  Transfer 

This  model  is  representative  of  an  information  transfer  system 
which  consists  of  a fixed  format  data  transfer  foreground  plus  an  interrupt  enabled  demand 
access  first-in,  first-out  background.  The  merits  of  this  system  are  anticipated  to  be 
twofold: 


• Reduced  bus  ioading 

• Reduced  delay  in  access  of  the  sporadic  data 

Some  of  the  assumptions  made  to  keep  this  model  simpler,  thereby  enabling  the  simulation 
to  cycle  faster,  are: 

• Error  and  failure-free  environment 

• Foreground-background  mode  similar  to  hybrid  analog- 
digital  real-time  operation  system 

• Foreground  with  fetch  messages  on  a fixed  telemevry 
format  comma  nd/response  basis.  Background  processing 
associated  with  demand  data  access  which  is  made  in 

a command/response  basis. 

• Interrupt  system  which  allows  the  central  control  to 
initiate  command/response  requests  for  the  demand 
access  data 

Some  other  assumptions  are:  one,  .hat  the  foreground  has  no  sporadic  data  transfer, that 
the  computed  bus  load  for  each  transfer  is  available  from  the  Static  Subsystem  in  a lumped 
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sequence  for  each  fundamental  update  interval;  two,  that  the  command  response  for  this 
demand  access  data  is  initiated  by  centra!  Central  therefore  knows  the  length  of  data 
transmission  for  each  demand  access  message  and  consequently  doesn't  initiate  a demand 
message  transfer  which  could  interfere  wrfh  the  next  foreground  transmission.  Only  demon  a 
message.,  which  have  arrived  prior  to  the  end  of  foreground  transmission  are  considered 
for  transmission  during  the  following  background  period. 


Mode!  D8  - Demand  Access  Transfer  Including  Considerations 
of  Redundancy  and  Fault-Handling  Schemes 

Basically,  Model  DB  is  a more  sophisticated  version  of  Model  DA. 

It  represents  a system  which  consists  of  foreground  fixed  format  message  transmission  and 
control  plus  c.emcna  access  background  message  queueing.  ”ne  demand  access  messages 
are  rrc'ismitted  or  dispatched  after  completing  the  fixed  message  requirement.  They  are 
tran  mitred  on  a first-in,  first-out  order. 

This  model  takes  into  account  the  impact  of  noise  on  the  dual 
redundant  data  bus.  In  this  model  both  aata  buses  must  be  impacted  by  a ncise  event 
during  transmission  of  the  same  message  for  a failure  to  result.  Bus  failures  are  generated 
in  this  model  by  using  a noise  event  of  infinite  duration.  Either  bus  can  be  made  to  fail 
independently.  The  foreground  dispatching  of  messages  is  on  a message-by-message  basis 
instead  of  Just  a fixed  non-varying  sequence  group  as  was  done  in  model  DA.  This  is 
necessary  to  evaluate  the  impact  of  noise  on  the  message.  The  message  is  also  separated 
into  the  command  segment  and  the  response  segment  for  separate  evaluation.  Failure, 
can  be  acknowledged  by  either  a non-resportding  terminal  or  a failure  of  the  controller 
to  recognize  the  response.  A failure  is  aiso  determined  by  a watch-dog  timer  event 
occurring  before  a given  message  response. 

Each  terminal  can  be  caused  to  foil  by  occurrence  of  a failure 
event.  There  are  two  failed  modes:  permanent  disable  or  intermittent  (that  is, a terminal 
which  recovers  from  a failure  after  a period  of  time.) 

Associated  with  each  message  there  is  a response  time  which  :s 
uniformly  distributed.  This  brings  up  the  point  that  under  this  situation  a con  roller 
cannot  predict  the  length  of  time  for  transmitting  a message.  In  particular,  the  controker 
checks  the  length  of  time  for  an  average  message  transmission  and  if  it  is  less  than  the 
time  to  the  start  of  the  next  FU1  time  it  schedules  its  occurrence.  However,  because  of 
the  nature  of  a variable  response  or  a failed  response, a feature  was  built  to  allow  a delay 
of  the  next  FU I fixed  format  message  transmission  until  the  completion  of  the  present 
transmission . This  element, along  with  variances  in  response,  contributes  j it  er  to  the 
fixed  format  transmission  schedule. 

Basically  all  the  key  features  of  model  DA  are  incoroorated  into 
Model  DB.  However,  it  takes  longer  to  cycle  through  an  equivalent  simulated  time  than 
ii  aoes  forModel  DA,  and  therein  iies  the  importance  of  having  both  models 


123 


Failure  models  that  have  no  fixed  FUI  requirements  can  be  formu 
lated  from  either  model . This  is  strictly  c demand  message  transfer  system. 

b.  How  Do  I Use  It? 


Basically  the  beginner  or  basic  user  will  rely  on  the  User'sManual . 
The  overall  MUXS1M  system  specified  and  thereby  implemented  is  an  interactive  set  of 
software  with  optional  coaching.  The  coaching  feature  was  implemented  to  make  the 
use  of  MUXSIM  easy  for  the  beginner.  This  interactive  software  is  the  reason  for  the 
Executive  Subsystem.  The  coaching  feature  can  be  switcned  off  for  the  more  mature 
basic  user  who  doesn't  want  to  be  hampered  with  the  rime  delay  for  the  coaching  inter- 
change. The  veteran  or  advanced  user  will  make  use  of  System  Modification  Design 
Data  Manual  to  create  programs  which  are  tailored  to  his  specific  requirements  and 
install  them  into  the  MUXSIM  software  system. 

An  anticipated  basic  user  scenario  of  MUXSIM  is  described 
pictorally  in  Figure  B-5  and  is  explained  briefly  in  the  following  three  steps: 

(1)  For  the  MUXSIM  user,  the  sofware  system  structure  can  be 
considered  to  consist  of  two  parts: 

• The  MUXSIM  software  programs  which  control  user 
interaction  and  the  actual  simulation  routines. 

• System  Definition  Libraries  which  consist  of  a family 
of  possible  system  configurations  the  user  may  desire, 
and  workloads  (signal  lists)  which  the  user  will  model 
into  the  system;  a special  signal  list  must  be  manually 
compiled  by  the  user  first. 

(2)  The  user,  sitting  at  an  interactive  CRT  or  TTY  console, 
is  coached  by  the  MUXSIM  Executive  Subsystem  through 
the  desired  sequence  of  programs.  As  he  progresses: 

• He  will  select  the  signal  list  he  wants  in  his  system 
model  from  his  workload  library.  The  Signal  List, 
which  contains  the  definition  of  each  signal,  and 
the  Equipment  Location  Dictionary, can  be  compiled 
either  from  the  workload  (Signal  List)  library  by 
using  an  Equipment  Complement  or  by  entering  a 
manually  prepared  signal  Iistan4/°r  dictionaries. 
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• He  can  make  any  custom  changes  to  these  lists  that 
he  desires. 

• He  selects  a model  for  the  kind  of  system  he  wishes: 
central,  federated,  command  response,  user  demand, 
sequential,  etc.  The  System  Configuration  Model  is 
normally  ca'led  from  the  System  Configuration  Model 
Library  contained  in  either  static  or  dynam'ic  sub- 
systems. Each  model  has  a set  of  System  Specific 
Parameters  with  it.  Hov/ever,  they  can  be  modified 
from  the  user's  console.  Additional  models  might  be 
obtained  by  using  one  of  the  existing  models  as  a 
guide  for  coding  new  models.  The  models  are  mod- 
ular in  construction  and  a wide  variety  of  additional 
models  can  be  covered  by  a few  basic  modifications. 

(3)  The  MUXSIM  software  will  take  over  after  each  program 
selection  and  will  progressively  supply  the  user  the 
specific  contrcct  data  indicated  in  Figure  B-5  for  his 
system.  The  compressed  Signal  List,  plus 
accompanying  dictionaries  available  from  the  original 
Signal  List  in  the  workload  library /are  used  to  provide 
comprehensive,  user-readable  printouts  v'hich  include: 

• RT/Equipmer.t  interface  to  the  pin  assignment  level 
of  detail 

• Message  Structure  and  Message  Processing  require- 
ments to  the  signal  level  of  detail 

• Message  Scheduling  for  each  fundamental  update 
interval 

• Bus  Usage  and  Utilization  Reports 

• Time  Deiay  and  Message  Queueing  Statistics 

This  printout  provides  a highly  detailed,  well -documented 
definition  of  the  system  requirements  which  enchances  the 
writing  of  system  and  module  specifications. 
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3. 


LOGICAL  CONSTRUCTIONS 


The  MUXSIM  design  phase  identified  the  requirement  for  four  major  software 
subsystems:  Executive,  Utility,  Static,  and  Dynamic,  as  shown  in  Figure  B-l. 

However,  the  major  partitioning  of  the  software  construction  effort  was 

twofold: 

• User  Ease  Software,  which  consists  primarily  of  the  Executive  Module 
with  its  interactive  features,  and  is  designed  specifically  to  complement 
the  TOPS-IO  operating  system  for  user/system  interface. 

• Operation  Software,  which  consists  of  the  Utility,  Static,  and 
Dynamic  modules  and  contains  the  software  which  does  the  data 
manipulation  and  algorithms  necessary  to  perform  the  simulations. 

The  former  consists  of  a software  system  which  supports  the  user/MUXSIM 
interface.  The  primary  interface  is  achieved  between  the  user  and  the  Executive  module 
software.  Other  interface  requirements  make  use  of  the  TOPS-IO  interactive  features. 

The  latter  consists  of  the  programs  which,  when  run  batch,  would  produce 
the  desired  simulation  results. 

The  two  were  developed  separately.  The  requirement  for  the  software  system 
design  effort  was  to  evolve  a set  of  operational  software  programs  each  of  which  would 
run  in  batch  mode  initially.  Due  to  system  functional  requirements  when  the  programs 
were  integrated  into  the  system,  they  run  in  pseudo-batch  fashion.  That  is,  the  program 
would  be  called  to  run  in  a batch-like  sequence,  the  main  difference  being  that  they  are 
called  interactively  from  the  Executive  subsystem. 

The  user  ease  software  consists  of  a set  of  software  programs  which  would 
marry  the  operation  software  to  TOPS-IO.  The  set  consists  of  a main  executive  program 
which  is  a tree  structure  and  permits  accessing  any  operation  program  by  following  the 
proper  calling  branch.  This  structure  is  mandated  by  the  requirement  for  coaching  the 
user  through  a set  of  questions  about  his  requirement,  to  direct  him  to  the  proper  program. 
Other  user-ease  programs  were  developed  to  enable  him  to  use  the  system  efficiently. 

The  tree  structure,  or  main  executive  subsystem  program,  was  developed  standalone  by 
using  chain  back  to  the  Executive,  which  returned  the  user  to  the  point  of  departure  when 
an  operation  program  was  called.  A special  LDFILE  program  was  also  constructed  to  create 
the  coaching  text  file. 

The  system  was  married  by  chaining  from  the  proper  point  in  the  main  execu- 
tive program  to  the  individual  operation  programs,  and  at  the  end  of  program  execution 
chaining  from  the  program  back  to  the  main  executive  program. 
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The  main  structure  of  the  operation  software  system  was  that  of  progressively 
manipulating  (mapping)  the  signal  list  through  a series  of  three  grouping  criteria,  each 
dependent  on  the  prior  one.  This  functional  requirement  translated  into  a logical  require- 
ment for  a string  of  programs,  each  of  which  is  driven  by  an  input  file  and  generates  an 
output  file  which  serves  as  the  input  file  for  the  next.  The  last  two  files  created  one 
static  mode  I -dependent.  In  essence  this  progressive  file  manipulation  provides  the  major 
interprogram  communication  link  for  the  operation  programs  data  manipulations.  The 
approach  was  debugged  early  by  running  the  programs  batch  in  the  proper  sequence;  in 
fact,  the  programs  were  developed  in  that  sequence  to  minimize  interprogram  data-inter- 
face  problems.  Other  satellite  programs  which  are  required  to  either  document,  summarize, 
and/or  evaluate  the  file  contents  were  also  developed  after  the  program  which  created 
that  specific  file . 

a.  Operation  Software  Construction 

The  top-level  flow  of  the  operation  software  is  illustrated  in  Figure  B-2. 

It  shows  the  functional  interplay  of  the  present  implementation  of  the  three  major  operation 
subsystems:  Utility,  Static,  and  Dynamic.  These  major  subsystems  are  divided  into 
programs . 

However,  Figure  B-2  shows  the  Static  subsystem  subdivided  into  five 
major  functions.  This  was  done  because  functionally  it  is  easier  to  explain  the  operation 
system  from  this  breakdown.  The  Executive  subsystem  calling  sequence  to  the  programs 
in  the  Static  subsystem  has  an  intermediate  step  between  the  call  to  the  subsystem  and 
the  call  to  the  individual  program.  This  intermediate  call  subdivides  the  programs  into 
three  different  groupings:  RT  ASSIGN  (RT  assignment),  BUS  USAGE  (bus  usage),  and 
BUSSCHDL  (bus  schedule).  This  subdivision,  or  one  much  like  it,  was  necessary  simply 
because  when  a call  to  HELP  was  initiated  at  this  level,  the  coach  text  display  would 
exceed  the  CRT  screen  line  limitations.  Five  subdivisions  were  considered  excessive. 

The  Utility  subsystem  has  two  intermediate  steps,  one  for  inputting  the  signal  list  and 
one  for  recovering  tne  signal  list.  Each  one  calls  two  programs.  The  other  programs  are 
called  directly.  The  Dynamic  subsystems  programs  are  called  directly  after  call  to  the 
subsystem . 

(1)  Utility  Subsystem  Construction 

As  part  of  the  software  system  design,  the  Utility  sybsystem  was 
divided  into  eight  ta.ks,  each  to  be  handled  by  separate  programs  as  shown  in  Figure  B-3. 
The  eight  tasks  are  a;  follows: 

• Inputting  the  signal  list  from  card  or  card  image  tape  and 
extraction  of  dictionaries  from  selected  fields  for  the 
explicit  purpose  of  reducing  the  on-line  storage  require- 
ments for  the  signal  list. 
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• The  interactive  editing  of  individual  signals  in  the  on-line 
signal  list. 

• Reconstruction  of  the  full  text  signal  list  from  the  compacted 
signal  list  and  associated  dictionaries  and  the  off-line 
(tape)  storage  in  record  image  of  this  list  and  an  associated 
printout  of  same  list. 

• Inputting  the  signal  list  from  record  image  tape  and 
extracting  the  dictionaries  from  selected  fields,  as  with 
the  card  image  inputs. 

• Extraction  of  input  and  output  signal  flow  summaries  from 
the  signal  list,  with  the  restriction  that  only  signals  derived 
can  be  used  for  the  summaries  pertaining  to  each  LRU. 

(This  is  used  to  compare  and  account  for  double  entries 
created  by  identical  intersubsystem  signal  information  being 
extracted  from  the  different  hardware  subsystem  documen- 
tation.) 

• Comparison  of  the  input  versus  output  summaries  for  the 
matching  pair.  The  documentation  of  those  input  and 
output  signal  flow  summaries  which  do  not  pair  with 
summaries  in  the  complement  list. 

• Reconstruction  of  the  full  text  signal  list  for  only  the  inpur 
or  output  signal  flow  summary  (thereby  deleting  double 
entry  signals).  This  is  accomplished  by  using  the  compacted 
signal  list  and  associated  dictionaries;  its  outputs  are  the 
off-line  (tape)  storage  in  record  image  of  this  list  and 
associated  printout. 

• Special  modification  of  the  signal  list,  specifically  the 
LRU  keys.  This  program  models  the  data  for  hardware 
modification  involving  the  LRU  separation  of  inputs  and 
outputs  and/or  merging  of  several  LRU's  into  a single  LRU. 

The  data  or  functional  flow  among  these  eight  progrcms  is  shown 
in  Figure  B-3.  The  actual  program  flow  diagrams  and  program  listings  are  contained  in 
the  MUXSIM  System  Modification  Design  Data  Manual.  Each  individual  program's  input/ 
output  interfaces  are  shown  in  Figure  B-6. 

(2)  Static  Subsystem  Construction 

The  Static  subsystem  was  functionally  divided  into  five  tasks. 

These  tasks  were  functionally  d'vided  into  eleven  programs.  The  first  task  was  RT  Assign; 
that  is,  the  task  of  mapping  the  signals  into  remotely  located  signal  collection  and 
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(USER 

DICTIONARY) 


EXTSFS  PROGRAM 


SIGNAL  FLOW 
SUMMARY  FILE 


SIGNAL  FLOW 
SUMMARY  LISTING 
INCLUDING 
DISCREPANCY 
LISTING 


•PRIOR  TO  USING  THIS  PROGRAM  OR  MUXSIM  FUNCTION,  THE  USER  SHOULD 
CREATF  & CARD  IMAGE  FILE  WHICH  IS  ACCESSIBLE  BY  MUXSIM.  THIS  FILE  IS 
USED  AS  INPUT  BY  THIS  PROGRAM  OR  MUXSIM  FUNCTION.  (REFERENCE  THE 
MUXSIM  USER’S  MANUAL.) 

Figure  B-6. 

Utility  Subsystem  Programs  and  Respective  Input/Output  Interfaces 

(Sheet  1 of  2) 
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•PRIOR  TO  USING  THIS  PROGRAM  OR  MUXSIM  FUNCTION,  THE  USER  SHOULD 
CREATE  A CARD  IMAGE  FILE  WHICH  IS  ACCESSIBLE  BY  MUXSIM.  THIS  FILE  IS 
USED  AS  INPUT  BY  THIS  PROGRAM  OR  MUXSIM  FUNCTION.  (REFERENCE  THE 
MUXSIM  USER'S  MANUAL.) 

Figure  B-6. 

Utility  Subsystem  Programs  and  Respective  Input/Output  Interfaces 

(Sheet  2 of  2) 
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dispersion  points.  This  task  requires  a high  cegree  of  human  interaction  and  selection. 

The  pictorial  description  is  shown  in  Figure  B-7  and  indicates  that  it  was  subdivided  into 
six  subtasks,  each  to  be  handled  by  separate  programs.  These  subtasks  are: 

• Sort  LRU's  by  LRU  location  and  RT  assignment  (if  one 

has  been  made  on  the  LRU  LOCATION  and  RT  assignment 
card).  Printout  LRU  key,  location,  and  RT  number. 

• Sort  LRU's  as  above.  Print  out  LRU  key,  name,  location, 
and  RT  number  (if  assignment  has  been  made  on  dictionary). 

• Sort  signals  by  LRU  location  and  RT  assignment  (if  one  has 
been  made  on  the  individual  SFS).  Print  out  signal  quantities 
by  type  and  LRU,  location,  and/or  RT  assignment. 

• Assignment  of  LRU  number  from  LRU  location  RT  assignment 
dictionary  to  individual  signal  summaries  on  the  signal  flow 
summary  file  (SFSF). 

• Edit  the  individual  signal  summaries  to  reassign  RT's  or  to 
split  signals  into  two  or  more  summaries  and  reassign  RT's 
for  each  new  summary. 

• Document  the  individual  signal  to  RT  assignment.  This 
documentation  to  be  as  text-rariented  as  possible. 

The  second  task  was  that  of  mapping  the  signals  into  words  on 
pre-hardware  models  which  are  to  be  transmitted  on  the  data  base.  This  task  is  model- 
dependent  and  is  done  with  no  added  human  intervention.  It  was  assigned  to  a single 
program  which  created  the  word  flow  summary  file.  (See  Figure  B-8.) 

The  third  task  was  that  of  mapping  the  word  assignment  into  messages 
such  as  is  done  by  the  hardware  implementation  which  is  being  modeled,  and  to  document 
the  signal-to-message  assignment  in  a text-oriented  format.  The  task  was  assigned  in  two 
programs:  one  which  created  the  message  flow  summary  file;  the  other  to  handle  the 
documentation.  (See  Figure  B-9.) 

The  fourth  task  was  that  of  computing  the  bus  data  rate  loading 
and  utilization.  This  task  was  assigned  to  one  program.  (See  Figure  B-10.) 

The  fifth  task  was  that  of  assigning  messages  to  fundamental  update 
intervals  (also  known  in  telemetry  as  "minor  frames")  and  computing  the  individual  funda- 
mental update  interval's  bus  loading  and  utilization,  and  displaying  the  results  in  time-line 
display.  This  task  was  assigned  to  one  program.  (See  Figure  B-ll.) 
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(INCLUDES  RAW  DATA  RATES 
F OR  LRU,  LOCATION  & RT 
ASSIGNMENTS) 


•PRIOR  TO  USING  THIS  PROGRAM  OR  MUXSIM  FUNCTION.  THE  USER  SHOULD  CREATE  A 
CARO  IMAGE  FILE  WHICH  IS  ACCESSIBLE  BY  MUXSIM.  THIS  FILE  IS  USED  AS  INPUT  BY 
THIS  PROGRAM  OR  MUXSIM  FUNCTION.  (REFERENCE  THc  MUXSIM  USER'S  MANUAL.) 


••  SUMTYP  PROGRAM  USES  RT  ASSIGN  BY  RUSES  PROGRAM  NOT  THE  DICTIONARY  INPUT. 

Figure  B-7. 

Static  Subsystem  RT  Assign  Task  Programs  and  Respective  Input/Output  interfaces 

(Sheet  1 of  2) 
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•PRIOR  TO  USING  THIS  PROGRAM  OR  MUXSIM  FUNCTION,  THE  USER  SHOULD 
CREATE  A CARD  IMAGE  FILE  WHICH  IS  ACCESSIBLE  BY  MUXSIM.  THIS  FILE  IS 
USED  AS  INPUT  BY  THIS  PROGRAM  OR  MUXSIM  FUNCTION.  'REFERENCE  THE 
MUXSIM  USER’S  MANUAL.) 

Figure  B-7. 

Static  Subsystem  RT  Assignment  Task  Programs  and 
Respective  Input/Output  Interfaces 
(Sheet  2 of  2) 
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Figure  B-9 

Static  Subsystem  Message-tv-Woro  Mopping  Task  Programs  and  Respective 
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Figure  B— 1 0 

Static  Subsystem  Bus  Loading  and  Utilization  Task  Program,  and 
Respective  Input/Output  Interfaces 
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Figure  B-l  1 

Static  Subsystem  Fixed  Format  Schedule  Task  Program  and 
Respective  Input/Output  Interfaces 
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(3)  Dynamic  Subsystem  Construction 

As  part  of  the  software  system  design,  the  Utility  system  was  dividea 
into  two  functional  tasks,  each  to  be  handled  by  o separate  program.  These  two  tasks  are: 

• Simulation  of  a Demand  Access  Data  Transfer  System  which 
has  fixed-format  data  transfer  via  foreground  dedicated 
transfer  with  a separate  hardwire  interrupt  process  to  queue 
the  demand  access  background  messages  for  transmission 
af'er  completion  of  fixed  format  data  transfer. 

• Simulation  of  a Demand  Access  Data  Transfer  System  which 
has  the  same  features  as  above,  but  takes  into  account 
impact  of  noise  and  component  failures  on  the  system,  as 
well  as  system  transmission  jitter  on  the  fixed-format 
message  sequence . 

The  data  or  functional  flow  between  the  other  subsystems  and  the  dynamic  subsystem  is 
shown  in  Figure  B-2 . Each  of  these  programs  functions  independently  of  the  other.  Each 
individual  program's  input/output  interfaces  are  shown  in  Figure  B—  1 2 . 

(4)  Signal  List  Inputs  and  Progressive  File  Construction 

The  basic  system  architecture  consists  of  progressively  manipulating 
the  original  data  base  from  its  input  format  into  its  basic  message  structure.  There  are 
in  this  MUXSIM  implementation  six  distinct  stages  or  evolutions  in  which  the  originc 
workload  information  can  exist.  They  consist  of  two  input  stages: 

• Card  image  or  preliminary  Signal  List  input 

• Record  image  or  intermediate  Signcl  List  inputs 

Both  of  these  forms  are  stored  off-line  to  MUXSIM.  The  second 
form  is  derived  by  entering  and  then  retrieving  the  data  from  the  MUXSIM  input  storage 
area.  There  are  four  on-line  states  in  which  the  data  base  can  exist,  as  follov/s: 

• Compacted  Signal  List  file  and  Signal  List  Dictionary 
file  (7) 

• Signal  Flow  Summary  (SFS)  file 

• Word  Flow  Summary  (WFS)  file 

• Message  Flow  Summary  (MFS)  file 

All  other  basic  manipulations  and  computations  are  centered  around  the  derivation  cf  these 
progressively  manipulated  data  inputs  or  files.  The  description  of  each  data  stage  is  de- 
tailed in  the  following  paragraphs . 
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USER  INPUTS  CONSIST  OF: 

1 . GASP  IV  CONTROL  CARDS 

2.  USER  NON-GASP  VARIABLE 
WORKLOAD  DEFINITIONS 
(TABLE  INPUT) 


•PRIOR  TO  USING  THIS  PROGRAM  OR  MUXSIM  FUNCTION,  THE  USER  SHOULD 
CREATE  A CARD  IMAGE  FILE  WHICH  IS  ACCESSIBLE  BY  MUXSIM.  THIS  FILE  IS 
USED  AS  INPUT  BY  THIS  PROGRAM  OR  MUXSIM  FUNCTION  (REFERENCE  THE 
MUXSIM  USER'S  MANUAL). 


Figure  B-12 


Dynamic  Subsystem  Programs  and  Respective  Input/Output  Interfaces 
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1 . Card  image  or  preliminary  Signal  List  input. 

The  information  is  contained  in  either  cards  or  card  image 
tape  where  the  information  for  each  signal  is  contained 
in  00-column  card  format  spread  over  three  card  types. 

The  dcta  is  sepaiated  by  hardware  subsystem  within  which 
the  cards  are  grouped  in  the  following  sequence:  all 
Type  1,  followed  by  all  card  Type  2,  and  then  all  card 
Type  3.  (See  Figure  B-13) 

2.  Record  image  or  intermediate  Signal  List  input. 

This  information  is  contained  in  tape  where  the  information 
for  each  signal  is  a recora  and  each  entry  into  the  signal 
list  is  a defined  field  within  the  record.  The  records  are 
sequenced  by  ascending  signal  ID  number.  This  input  is 
normally  recreated  by  the  MUXSIM  software  from  input 
through  reconstruction  from  the  compacted  signal  list 
file  and  dictionary  files. 

3.  Signal  List  Dictionaries  and  compacted  Signal  List  files. 

These  files  are  contained  in  disk  or  other  random  access  mass 
storage  areas  where  the  information  for  each  signal  is  a 
record  and  each  entry  into  the  signal  list  is  a field.  However 
seven  of  the  fields  are  represented  by  numbers  which  are 
cross-references  to  dictionaries  which  have  been  extracted 
and  stored  in  the  signal  list  dictionary  files  EXTDIC  program 
for  the  seven  fields  in  order  to  compress  the  storage  size 
requirements  for  the  signal  list. 

4.  Signal  Flow  Summary  (SFS)  file. 

This  file  is  contained  in  disk  or  other  random  access  mass 
storage  area.  The  information  contained  is  a count  of  the 
number  of  signals  that  satisfy  the  following  criteria(along 
with  the  criteria  themselves): 

• signal  input  or  output  from  LRU 

• origin  LRU 

• destination  LRU 

• signal  type  (s) 

• update  rate 

• quantization  word/bit 
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The  information  consists  of  o record  header  with  the  variables 
of  search  and  the  signal  ID  of  the  signal  which  is  part  of  the 
group.  The  information,  for  reasons  of  storage  constraints, 
has  a limited  physical  record  size.  It,  therefore,  could 
become  necessary  to  carry  a signal  ID  list  logical  record  over 
multiple  physical  records.  The  source  Signal  List  is  normally 
extracted  from  documents  (or  other  SFL's),  each  of  which  is 
used  to  describe  a subsystem  or  equipment  group.  As  shown 
or  equipment  group.  As  shown  in  Figure  B-14,  the  subsystem 
interconnects  are  normally  listed  as  outputs  from  one  subsystem 
and  again  listed  as  inputs  to  another  subsystem.  The  intra- 
system signals  are  normally  entered  into  the  Signal  List  once 
only.  A manual  accounting  method  for  deleting  these  double 
entries  is  tedious  and  error-prone.  Therefore,  the  problem 
is  resolved  through  using  the  EXTSFS  programs  which  derive 
the  SFS  for  this  accounting.  This  is  accomplished  by  restrict- 
ing the  search  for  input  and  output  SFS  entries  for  each  LRU 
to  those  entries  in  the  SFL  which  were  derived  from  the 
subsystem.  This  restriction  is  accomplished  by  the  use  of  the 
Signal  Group-LRU  Assignment  Dictionary,  which  uses  the 
two  highest  digits  of  the  Signal  ID  as  a key  for  separation 
of  the  Signal  List  into  subsystem  origin.  When  creating  the 
SFS,  this  search  restriction  counts  the  intrasubsystem  signals 
twice,  once  as  an  output  from  an  LRU  and  again  as  an  input 
to  another  LRU.  The  intersubsystem  signals  were  double 
listed  in  the  Signal  List  and  this  search  restriction  only  caur.’s 
each  one  once . 

The  SFS  list  is  separated  by  input  and  output  ID  designators 
into  complementary  lists.  The  signals  which  were  derived 
from  a particular  subsystem  portion  of  the  list,  but  contain 
neither  origin  nor  destination  from  that  subsystem,  are  listed 
with  an  ID  designator  which  indicates  erroneous  or  question- 
able entries.  Other  categories  of  questionable  entries  are 
those  signal  summaries  which  have  either  an  acceptable  origin 
or  destination,  but  the  other  (origin  or  destination)  is  not 
contained  in  the  system  LRU  list.  The  following  is  a descrip- 
tion of  the  SFS  ID  designators: 

0 - Output  signal  summary  originating  from  an  LRU 

within  the  system. 

1 - Input  signal  summary  destined  to  an  LRU  within  the 

system . 
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2 - Output  signai  summary  originating  from  an  LRU 

within  the  subsystem  and  destined  to  an  LRU  not 
listed  within  the  system. 

3 - Input  signal  summary  destined  to  an  LRU  within 

the  subsystem  and  originating  from  an  LRU  not 
listed  within  the  system. 

4 -A  signal  contained  in  a subsystem  portion  of  the 

signal  list,  but  containing  neither  an  origin  or 
destination  LRU  from  that  subsystem. 

After  the  SFS  is  corrected  for  all  SFS  with  ID  designators  2, 

3,  and  4,  or  the  user  is  satisfied,  the  input  and  output  (1,0) 
are  matched.  All  nonpaired  SFS  entries  are  listed  as  erroneous 
or  nonmatching  entries.  When  the  data  base  is  corrected  so 
that  the  complementing  lists  match  summary  for  summary, 
each  half  represents  the  signal  content  for  the  system  defined 
by  the  signal  list. 

5.  Word  Flow  Summary  (WFS)  file. 

This  information  is  usually  stored  in  disk  file.  Each  entry 
into  the  WFS  file  represents  a set  of  signals  which  match  the 
search  criteria  required  for  mapping  that  set  of  signals  into 
words.  The  principal  information  contained  in  the  entry  is 
the  number  of  words  generated  as  a result  of  that  mapping 
operation  of  that  set  of  signals. 

Like  the  SFS,  each  WFS  logical  record  entry  can  consist  of 
multiple  physical  records.  The  basis  entry  structure  contains 
a record  header  which  consists  of  the  variables  of  search  for 
that  mapping  and  a list  of  the  signal  ID  of  those  signals  which 
form  that  group.  The  signal  ID  in  this  can  also  overflow  into 
multiple  records. 

The  information  to  create  the  WFS  in  this  application  was 
derived  from  the  SFS  inputs;  it  can,  however,  be  derived 
from  the  compacted  signal  list  if  program  modifications  are 
made  to  incorporate  the  origin  and  destination  RT  assignment 
to  the  signal  records  and  the  signal  list  is  purgec  of  double 
entries. 
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The  search  criteria  for  grouping  the  signals  is  model- 
dependent.  The  search  is  controlled  by  the  EXTWFS 
program  of  the  static  subsystem.  The  model  selection 
is  made  interactively  by  the  user.  The  search  criteria 
for  the  different  static  models  usually  consist  of  the 
following  variables  which  are  contained  in  the  indi- 
vidual SFS  header  and  amended  by  the  EXTWFS 
program  in  accordance  to  the  specific  model  require- 
ment . 

• Update  Rate 

• Origin  Remote  Terminal 

• Destination  Remote  Terminal 

• Signal  Type  (Input/Output) 

• Quantization  Word/Bit  Number 

The  Data  Rate  and  Signal  Mapping  Algorithm  Dictionary 
is  used  to  input  the  system  specific  parameters.  It 
provides  the  key  for  grouping  signals  by  its  signal  type 
into  the  following  three  categories  which  are  essential 
to  the  mapping  operation: 

CATEGORY  A - MULTISIGNALS  TO  UNIWORD 
CATEGORY  B - UNISIGNAL  TO  UNIWORD 
CATEGORY  C - UNISIGNAL  TO  MULTIWORDS 

In  general  the  word  mapping  is  a procedure  of  counting 
the  number  of  words  involved  in  the  grouping.  In 
Category  A the  word  count  is  computed  by  dividing  the 
number  of  signals  in  the  group  by  the  quantity  of  signals 
per  word  (dictionary  entry)  and  rounding  up  to  the  next 
integer  number.  In  Category  B the  word  count  is  com- 
puted as  the  number  of  signals  within  the  group.  In 
Category  C the  word  count  for  each  signal  is  set  equal 
to  the  quantization/word  bit  number  or  is  set  equal  to 
a fixed  number.  The  choice  is  made  via  the  dictionary. 

Therefore,  as  a result  of  the  operation  each  entry  of 
the  WFS  file  represents  a number  of  words  on  the  data 
bus,  the  quantity  of  which  is  defined  by  this  process. 
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if  in  future  mode  s it  became  necessary  to  map  signals 
to  bytes,  this  orcgram,  with  minor  modification,  or 
one  like  it,  could  be  used  to  do  the  task.  The  byte- 
to-word  map  cojld  conceivably  be  modeled  like  the 
word-to-message  map.  The  operation  of  creating 
bytes  insteaa  of  words  would  represent  a very  similar 
operorion  (excepi  possibly  for  quantity  of  bits). 

Message  Flow  Sumn  ary  (WFS)  File. 

This  information  Is  usually  stored  in  disk  file.  Each 
entry  into  the  MFS  file  represents  a distinct  data  bus 
message.  The  message  is  composed  of  a set  of  signals 
which  were  associated  with  one  or  more  WFS  entries, 
all  of  which  satisfied  the  criteria  for  being  grouped 
together  into  a message.  The  principal  information 
contained  in  the  entry  is  the  number  of  words  required 
to  ca'ry  the  information  and  the  total  number  of  words 
(information  pius  overhead)  required  for  message  trans- 
mission . 

Like  the  SFS  and  WFS,  the  MFS  entry  consists  of  multiple 
records  with  a header  structure,  plus  a collection  of 
signal  ID's  which  can  overflow  into  multiple  records. 

The  information  to  create  the  MFS  file  has  to  derive 
from  the  prior  data  format,  in  this  case  the  WFS  file. 

The  criterion  for  grouping  the  words  into  messages  is 
mode  I -dependent  and  is  contained  in  the  Static  subsystem. 
The  model  specific  parameters  required  to  establish  a 
maximum  number  of  words  are  a user  input.  This  is 
the  only  additional  information  required  to  run  EXTMFS 
besides  WFS  file . 

If  a program  was  set  for  additional  mapping  requirements, 
such  as  byte-to-word-to-message,  sections  of  this 
mapping  approach  might  be  useful  in  byte-to-word 
mapping  requirements. 

This  MFS  file  is  the  final  evolution  of  the  data  base  for 
the  application  considered  in  the  initial  implementation 
phase  of  MUXSIM.  It  serves  as  the  information  source 
for  bus  loading  computation  and  bus  scheduling  requite- 
ments.  Eventually,  when  a more  sophisticated  data  base 
becomes  available,  this  would  serve  as  the  input  or 
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Workload  Library  for  the  Dynamic  models.  The  data 
base  in  this  case  would  have  to  define  those  signals 
involved  in  terms  of  stochastic  processes,  defining 
their  information  transfer  or  signalling  requirements. 

b.  User  Ease  Software  Construction 


The  user  ease  software  construction  stems  mainly  from  the  requirement 
to  create  a coached  interactive  system  which  makes  the  learning  and  use  of  the  MUXSIM 
simple  and  convenient  to  the  user.  This  user  ease  software  is  contained  in  the  Executive 
subsystem  and  consists  of  the  following  functional  requirements: 

e System  startup 

• Tree  structure  for  pointing  to  proper  program  or  task  selection 

• Capability  to  automatically  sequence  through  a set  of  programs 
in  batch-like  mode. 

© Generate  running  (set)  batch  mode 

o Copy  on-line  files  to  back-up  tape 

© Create  on-line  files  from  back-up  tape 

• A set  of  other  secondary  commands  which  add  usage 
convenience,  including  a special  program  to  construct  run 
batch  sequence 

e A system  to  construct  and/or  modify  the  coaching  text 
associated  with  the  tree  structure 

The  logical  requirements  which  followed  the  preceding  eight  functional  requirements 
resulted  in  the  following  five  programs  being  defined: 

© Program  to  initialize  or  start  up  MUXSIM. 

o Program  which  steps  and  tracks  the  user  through  the  tree 
structure,  contains  the  secondary  command  functions, 
controls  the  sequencing  through  automatic  set  batch 
mode  runs,  and  controls  exit  from  set  batch  mode  sequence. 

• Program  which  loads  the  coaching  text  files  for  use  by  the 
tree  structure.  (This  program  is  run  in  batch  mode  only  and 
is  not  accessible  through  the  tree  structure  main  program). 

• Program  to  copy  on-line  files  to  back-up  tape. 

• Program  to  create  on-line  files  from  back-up  tape. 
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Unlike  the  other  subsystem;,  theie  is  no  data  flow  involved  in  the 
Executive  subsystem.  The  actual  program  flow  diagrams  and  program  listings  are  contained 
in  the  System  Modification  Design  Data  Manual.  Each  individual  program's  input/output 
interfaces  are  shown  in  Figure  B-15. 

A feature  of  particular  interest  to  the  MUXS1M  user  is  the  ease  with 
which  the  task-calling  mnemonics  in  he  tree  structure  can  be  modified  into  terms  which 
are  easier  for  a particular  set  of  uses  at  c given  facility.  The  only  requirement  is  to 
modify  the*  proper  file  entry  via  a change  of  input  card  to  this  file.  The  task  is  tracked 
by  the  ocsition  of  the  entry  in  the  file.  When  a calling  mnemonic  is  entered,  the  file 
is  searched  and  located,  then  the  MUXSiM  task  which  corresponds  to  the  given  entry 
location  is  called.  The  actual  correlation  between  the  interactive  file  mnemonics  and 
program  names  and  the  tree  structure  that  were  used  for  the  system  test  are  shown  in 
Figure  8-16.  The  figure  contains  the  interactive  calling  mnemonics  and  the  program 
name  immediately  below  it  in  parentheses.  All  commands,  including  the  secondary  com- 
mands, can  have  their  calling  mnemonics  changed.  However,  for  this  implementation 
the  secondary  commands  are  parts  of  the  main  Executive  (tree  structure)  programs;  their 
names  were  left  the  same,  no  second  names  are  shown  in  parentheses. 

The  secondary  commands  that  were  functionally  required  to  assist  the 
user  through  the  MUXSIM  were  included  as  part  of  the  MUXSIM  main  program  or  tree 
structure  program.  They  are  listed  in  Figure  B-16  under  SCT;  their  functions  are  described 
in  Table  B-l . 

4.  PHYSICAL  CONSTRUCTION 

The  MUXSIM  system  is  an  on-line  user  interactive  system.  It  is  intended  to 
be  driven  from  a TTY  or  CRT  user  station.  The  workload  library  and  user  dictionary, 
required  input  for  MUXSIM,  v/ill  be  entered  either  from  tape  or  cards.  All  of  the  detailed 
reports  will  be  output  via  line  printer,  in  addifon  to  user  console  summary  results.  Some- 
times, at  user  discretion,  additional  requirements  to  save  information  such  as  modified 
inputs  and  intermediate  files  or  results  will  require  an  output  tape. 

The  system  is  installed  from  card  image  tape  pr  cards,  it  consists  of  26 
programs,  three  common  subroutines,  and  one  Coaching  Text  file,  for  a total  of  9500 
cards.  It  also  requires  a GASP  IV  subroutine  library  which  consists  of  27  subroutines  and 
19  functions,  for  an  approximate  total  of  2200  cards.  The  workload  library  associated 
with  defining  the  A-7D  Avionics  Suite  which  was  used  with  MUXSIM  for  System  Test 
consisted  of  approximately  10,700  cards. 

While  the  MUXSIM  system  is  built  in  FORTRAN  to  enjoy  a high  degree  of 
machine  independence,  this  AFAL  version  has  been  specifically  tailored  to  run  on  the 
host  DEC  System-10  with  its  TOPS-10  operating  system.  In  additon,  in  order  to  install 
MUXSIM  or  re-install  after  modification,  the  system's  Fcrtran-10  and  MACRO  compiler 
are  also  required. 
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•PRIOR  IO  USING  THE  PROGRAM  OR  MUXSIM  FUNCTION  THE  USER  SHOULD 
CREATE  A CARD  IMAGE  FILE  WHICH  IS  ACCESSIBLE  BY  MUXSIM.  THIS  FILE 
IS  USED  AS  INPUT  BY  THIS  PROGRAM  OR  MUXSIM  FUNCTION.  (REFERENCE 
THE  MUXSIM  USER  MANUAL). 

Figure  B-15 

Executive  Subsystem  Programs  and  Respective  Input/Output  Interfaces 

(Sheet  1 of  2) 


15C 


i. 


/ 


: 


w 


MUXSIM  ON  LINE  FILES  TO  BE  MOVED 


CONSIST  OF. 


SGLCDS.DAT 

SGLCOM.DAT 

SGLDIC.DAT 

SFSFIL.DAT 

WFSFIL.DAT 

MFSFIL.DAT 

SGLADC.DIC 

DRSMAP.DIC 

LRUNME.DIC 


LRULOC.  DIC 

LRUKMY.DIC 

GSPDF1.DIC 

GSPDF2.DIC 

BATCH.CMD 

SFSRTA.DAT 


Figure  B—  1 5 


Executive  Subsystem  Programs  and  Respective  Input/Output  Interface. 
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MUXSIM  PROGRAM  TREE  STRUCTURE 


Table  B-l.  SECONDARY  COMMAND  DESCRIPTIONS 

HELP  - produces  the  coaching  text  required  to  advise  the  user  of  his  alterna- 

tives at  this  point  in  the  tree  structure. 

END  - terminates  all  choices  at  this  level  on  the  tree  structure  and  returns 

the  j<er  control  to  the  next  higher  level  on  the  structure. 

CMriLE  - serves  to  create  a file  which  is  intended  as  the  driving  file  when  the 
user  repeats  this  sequence  of  operations  using  the  automatic  set  batch 
mode. 

STOP  causes  an  exit  from  the  MUXSIM  system,  and  at  the  same  time  saves 

the  location  of  the  user  in  the  tree  structure,  so  that  when  the  user 
re-enters  MUXSIM  he  ccn  choose  to  return  to  the  identical  location 
and  resume  his  task. 

LOG  - copies  the  MUXSIM  commands  to  an  ASCII  print  file  for  record. 

NLOG  - halts  the  copying  of  MUXSIM  commands  to  a print  file. 

COACH  - is  the  enable  command  for  the  coach  text.  (It  should  be  pointed 

out  that  at  certain  levels  the  user  still  has  to  call  HELP  before 
getting  any  coach  text  displayed.) 

NCOACH  - disables  display  of  all  coach  text. 

IO  - enables  the  user  to  access  MUXSIM  internal  file  status  directory 

for  the  explicit  purpose  of  modifying  the  directory. 

PCT  - creates  a display  of  the  primary  commands  which  are  accessible  at 

that  point  in  the  program. 

SCT  - creates  a display  of  the  secondary  commands  which  are  accessible 

at  that  point  in  the  program. 


RESET  - resets  MUXSIM  files  and  switches  to  initial  condition. 

Caution:  this  command  recreates  initial  startup  condition 
(no  files  defined  in  the  internal  directory). 


installation  Requirement 


c . 


The  User's  Manual  contains  a detailed  section  on  installation 
procedure  for  MUXSIM  from  card  image  source.  The  procedure  gives  a step-by-step 
requirement  for  installation . It  consists  basically  of: 

0) 

Inputting  from  source  to  the  hest  system  and  erecting  individuc 
source  fiies  for  the  26  programs;  files  for  the  common  subrooti, 
and  a fiie  for  the  coaching  text. 

(2) 

Fortran- comp ii  ing  the  common  subroutines,  with  the  exception 
that  CHAIN  subroutine  is  assembiea  with  MACRO. 

(3) 

Compiling  the  first  program,  linking  it  with  rhe  common 
subroutines,  and  saving  on  SAVE  FILE. 

(4) 

Proceeding  with  the  next  program  until  ail  programs  are  in 
SAVE  FILE. 

(5) 

Calling  and  executing  LD  file  to  install  coach  text. 

The  Individual  program  card  count,  the  size  of  disk  source  file  in  blocks, 
and  the  size  of  each  SAVE  FILE  in  blocks,  are  shown  in  TableB-  il.  These  are  intended  to 
give  an  operator  the  physical  requirements  for  system  installation. 

b.  Usage  Requirements 


The  Users  Manual  contains  the  details  for  using  the  MUXSIM  system 
The  basic  procedure  consists  of: 

0) 

Loading  the  Signal  List  (either  from  card  or  rape)  and  the 
User  Dictionaries. 

(2) 

Initializing  MUXSIM  and  startup. 

(3) 

Calling  and  executing  the  necessary  MUXSIM  tasks  the 

proper  sequence  to  produce  the  required  reports. 

(4) 

Termination  of  task,  including  if  considered  necessary  by 
the  user,  copying  to  tape  ail  inputs  (including  moaifieb 
inputs;  and  intermediate  files  for  future  or  historicci 
reference . 

The  approximate  times  for  execution  of  the  individual  program  c,\  . 
in  TableB-li.  This  time  is  referenced  to  rhe  A-7D  WORDLOAD  Data  3c..  . 7 size  : 
the  data  base  and  the  size  of  each  of  the  progressive  files  ore  shown  In  Tabic  B-iii . ” 
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Table  6-11.  DEC  SYSTEM-10  MUXSIM  SYSTEM  PROGRAM 
SIZE  AND  TIME  INFORMATION 


Program  Name 


MS 

LDFILE 
MUXMAN 
CPYDTT 
CPYTTD 
EXTDIC 
EXTREC 
RECOVR 
SFSRCR 
EXTSFS 
SFSCOM 
LRUKMY 


SNORT 

SSNORT 

SUMTYP 


EDTSFS 

TCONUP 

EXTWFS 

EXTMFS 

COMBLU 

TMSGLT 

TSCHDL 

MUXDA 

MUXDB 


Card  Count 

Source  File  in 
Disk  Blocks 

39 

2 

79 

3 

1543 

72 

87 

11 

92 

11 

468 

55 

323 

38 

166 

20 

175 

21 

380 

45 

393 

47 

111 

14 

726 

86 

100 

12 

159 

19 

551 

65 

222 

27 

393 

47 

247 

29 

496 

59 

451 

53 

330 

39 

134 

16 

575 

31 

358 

21 

887 

41 

Disk  Block 


Execution  Time  for 
A-7D 

Data  Base  Test 
Case  (CPU  Time) 


NA 

0:12.7 
NA 
NA 
NA 
13:28.4 
9:13.2 
2:  54.0 
1:17.4 
13:28.2 
0:22.4 
1 :04. 6 
NA 
0:10.3 
0:16.6 
7:52.4 
0:21.1 
NA 
1:04.2 

L 0:19.1 
H 1:55.1 

L 0:11.4 
H 0:48.6 

L 0:07.1 
H 0:25.8 

0:13.5 

0:11.3 

1:12.9 

6:38.6 


Table  B-lll.  MUXSIM  INPUT  PHYSICAL  SIZE  (A-7D  WORKLOAD) 


SIGNAL  LIST  AND  PROGRESSIVE  FILES 


NAME 

UNITS 

SIZE 

CARD  IMAGE 
SIGNAL  LIST 

(CARD  COUNT) 

10,678 

RECORD  IMAGE 
SIGNAL  LIST 

(RECORD  COUNT) 

2,682 

COMPRESSED  SIGNAL 
LIST  FILE  SIZE 

(DISK  BLOCKS) 

1,699 

SIGNAL  LIST  DICTIONARY 
FILE  SIZE 

(DISK  BLOCKS) 

92 

SIGNAL  FLOW  SUMMARY 
FILE  SIZE 

(DISK  BLOCKS) 

147 

WORD  FLOW  SUMMARY 
FILE  SIZE  1 

(DISK  BLOCKS) 

60  (MODEL  DEPENDENT) 

MESSAGE  FLOW  SUMMARY 
FILE  SIZE  1 

(DISK  BLOCKS) 

44  (MODEL  DEPENDENT) 

USER  DICTIONARIES 


NAME 

CARD  COUNT 

SOURCE  FILE  IN  DISK  BLOCKS 

SIGNAL  GROUP/LRU 
ASSIGNMENT  DICTIONARY 

46 

7 

DATE  RATE  AND  SIGNAL 
MAPPING  ALGORITHM 
DICTIONARY 

19 

3 

LRU  NAME  DICTIONARY 

223 

30 

LRU  LOCATION  AND  RT 
DICTIONARY 

178 

24 

LRU  KEY  MODIFICATION 
DICTIONARY  2 

95 

13 

GASP  IV  CONTROL  CARDS 
AND  MODEL  DEFINITIONS 

53/39 

5/3 

model  dependent 

2 

only  necessary  if  LRU  MODIFICATION  is  needed  to  define  the  workload  for 
the  program . 
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user  dictionaries  sizes  are  also  contained  in  Table  B-lll . The  sizes  of  the  various  printout 
reports  are  shown  in  Table  B-|V.  These  figures  are  intended  to  supply  the  operator  a point 
reference  for  time  and  size  requirements  for  running  a MUXSIM  problem. 


Table  B-IV.  LINE  PRINTER  MUXSIM  REPORTS 


PRINTOUT  REPORT 


LINES 


SIGNAL  LIST  DICTIONARY  (SORTED) 

SIGNAL  FLOW  SUMMARY  REPORT 

SIGNAL  FLOW  SUMMARY  RT  ASSIGNED  REPORT 

FORMATTED  SIGNAL  LIST 

MATCHING/NON-MATCHING  COMPLEMENTARY 
INPUT/OUTPUT  SIGNAL  SUMMARIES 

LRU  SORTED  BY  LOCATION  AND  RT 
ASSIGNMENT 

LRU  NAME  SORTED  BY  LOCATION  AND  RT 
ASSIGNMENT 

TOTAL  SIGNAL  TYPES  BY  LRU  LOCATION 
& RT  ASSIGNMENT 

SIGNAL-TO-TERMINAL  ASSIGNMENT  LIST 

MESSAGE  BUS  LOADING  AND  UTILIZATION  REPORT 

SIGNAL-TO-MESSAGE  ASSIGNMENT  LIST 

MESSAGE-TO-FUNDAMENTAL  UPDATE  INTERVAL 
ASSIGNMENT  AND  TIME-LINE  ANALYSIS 

DA  SUMMARY  REPORTS 


DB  SUMMARY  REPORTS 


MUXSIM  COMMAND  LOG  FILE 
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SECTION  V 


VERIFICATION 


1.  INTRODUCTION 

The  verification  of  the  MUXSIM  System  consisted  of  four  parts:  Module  Test, 
System  Test,  Acceptance  Test,  and  an  Extended  Operational  Phase.  The  Module  Test  verified 
each  program  individually  and  was  conducted  after  the  program  was  built  and  installed  on  the 
DEC  System--10.  System  Test  was  the  conclusion  of  the  initial  MUXSlM  implementation  phase 
and  consisted  primarily  of  stepping  through  the  implementation  to  ensure  that  the  software 
package  satisfied  its  functional,  logical,  and  physical  requirements.  The  Acceptance  Test 
took  the  form  of  a final  sel  l-off  demonstration . This  test  requirement  is  contained  in  the 
MUXSIM  System  Test  Plan  (Ref.  10).  Figure  B-17  diagrams  the  MUXSIM  Test  Flow. 

The  true  verification  comes  during  the  field  operational  phase  which  is  to  follow. 
Normally,  the  verification  of  simulation  results  is  a difficult  task.  However,  because  MUX- 
SIM is  a computer-aided  design  and  design  verification. tool , its  usefulness  is  the  proof  of  its 
performance,  which  is  anticipated  to  be  two-fold:  (1)  its  contribution  to  Multiplex  System 
Technology,  and  (2),  more  realistically,  its  contribution  to  an  actual  Multiplex  System  Design 
and  Development  Program.  The  simulator's  true  versatility  depends  not  so  much  on  person,  L Inc 
able  to  run  the  implemented  models  (which  in  this  case  are  based  on  realistic  implement, ion 
problems),  but  rather  in  the  ability  of  a person  to  take  the  software  system  and  modify  it  easily, 
then  apply  it  to  his  specific  problem  whether  it  be  functional  or  a more  detailed  logical  model  . 

2.  MODULE  TEST 

The  prime  objective  of  module  test  was  to  verify  the  accomplishment  of  mile- 
stones in  the  software  development.  The  tests  were  required  to  be  specific  in  navure  in  order  :o 
demonstrate  the  achievement  of  the  programming  goal.  The  tests  were  not  required  to  demon- 
strate any  specific  model,  as  was  the  case  in  the  System  Test  or  Acceptance  Test.  This  was 
in  order  that  the  model  or  data  base  development  did  not  interfere  with  other  software  develop- 
ment. 


a.  GASP  Subroutine  Library  Module  Test 


The  GASP  Subroutine  Library  is  a commercial  simulation  package  which 
is  used  as  the  base  for  the  Dynamic  Subsystem  operation.  The  GASP  Module  Tes*  was  performed 
to  verify  that  the  portion  of  GASP  used  in  the  MUXSIM  Dynamic  Subsystem,  the  discrete  event 
simulation  feature,  performed  properly. 
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Figure  B— 17.  MUXSIM  Test  Flow  Diagram  (Sheet  2) 


b.  Executive  Subsystem  Module  iest 


The  Executive  Subsystem  provides  the  interface  between  TOPS-IO  and 
the  operator  and  the  other  subsystems.  During  module  test  the  Executive  Subsystem  was  tested 
with  dummy  modules  in  lieu  of  the  Utility,  Static,  and  Dynamic  Subsystems,  and  the  actual 
text  which  was  installed  by  the  LDFILE  program  and  verified  with  the  MSG  subroutine.  The 
module  test  was  conducted  as  a threefold  effort: 

1 . A verification  of  the  interface  approach  between  TOPS-IO  and 
MUXSIM  system  software. 

2.  Verification  of  all  the  interactive  coaching  texr  and  associated 
option  paths . 

3.  Verification  of  CHAIN  subroutine  separately,  prior  to  incorporation 
into  the  Executive  Subsystem  for  integration  with  the  remainder  of 

the  subsystem . 

c.  Utility  Subsystem  Module  Test 

The  prime  function  of  the  Utility  Subsystem  is  to  provide  the  user  a 
system  to  interface  with  the  workload  or  Signal  Flow  List.  The  Utility  Subsystem  manages  the 
Signal  Flow  List  and  extracts  simulator  inouts  from  it.  During  module  test,  the  Utility  Subsystem 
was  tested  by  executing  the  individual  subsystem  programs  batch  and  comparing  the  program  out- 
puts against  a set  of  results  derived  from  tests  on  the  Harris  Datacraft  6024/5  Computer  Facility. 
The  input  workload  was  the  A-7D  data  base. 

The  programs  were  executed  in  progressive  order  of  flow  to  assure  that 
the  output  results  were  available  for  inputs  to  the  succeeding  programs. 

d.  Static  Subsystem  Module  Test 

The  prime  function  of  the  Static  Subsystem  is  to  provide  the  user  a 
means  of  mapping  the  signals  in  a model -dependent  fashion  into  data  bus  traffic,  and  computing 
bus  loading  and  scheduling  of  the  fixed  telemetry  format  traffic.  During  module  test  the  Static 
Subsystem  was  tested  by  executing  the  individual  subsystem  programs  in  a batch  mode  and  com- 
paring the  program  output  against  a set  of  acceptable  results  derived  from  tests  on  the  Harris 
Datacraft  6024/5  Computer  Facility.  The  input  workload  was  the  A-7D  data  base. 

The  programs  were  executed  in  progressive  order  of  flow  to  assure  that 
the  output  resxiits  were  available  for  input  to  the  succeeding  programs. 

e.  Dynamic  Subsystem  Module  Test 

The  prime  function  of  the  Dynamic  Subsystem  is  to  provide  the  user  a 
means  of  conducting  simulation  of  random  message  scheduling  tasks  and  establishing  a measure 
of  bus  loading  and  time  delay  statistics.  During  module  test  the  Dynamic  Subsystem  was  tested 
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by  executing  the  individual  subsysrem  programs  batch  and  comparing  the  program  outputs  agair.s 
a set  of  acceptable  results  derived  from  tests  on  the  Harris  Datacraft  6024  5 Computer  Facility 
The  input  svorkioad  was  a synthetic  workload,  s'nce  an  actual  data  base  with  Stochastic  Signaling 
Definitions  was  not  available. 

3.  SYSTEM  TEST 

The  Sysrem  Test  demonstrated  that  MUXSIM  has  been  developed  with  the  capability 
to  accomplish  ‘he  requirements  wh:ch  were  specified  in  the  Statement  of  Work.  The  System 
Test  was  conducted  as  a two-foid  exercise- 

1 . Module  reverification 

2.  System  model  test 

The  first  part  was  needed  in  order  to  verify  that  changes  in  the  individual  programs  which  occurred 
after  undergoing  module  test  did  not  impair  the  program's  performance.  The  second  part  was 
the  actual  system  test  which  was  used  to  demonstrate  the  system's  capability. 

a.  Module  Reverification 

This  test  was  a variation  of  the  original  module  test,  and  in  some 
cases  was  expanded  to  include  features  created  since  the  module  tesr.  The  basic  difference 
between  the  original  test  and  this  test  is  that  this  test  served  to  exercise  the  following  models 

STATIC  MUX  MODELS 


Model  Name 


Information  Transfer  Discipline 


DYNAMIC  MUX  MODELS 


T/T  Transfer 


T/C/T  Transfer  (bit  shuffling) 

T/T  Transfer  with  BCIU  Broadcast 


Model  Name 


Description 


Mode!  of  MUX  system  using  a 
demand-access  discipline. 

Model  of  MUX  system  utilizing 
command-response  information- 
transfer  disciplines  with  redun- 
dancy fault-handling  schemes . 
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b.  System  Model  Test 


This  was  the  actual  system  verification  test.  The  test  consisted 
primarily  of  rerunning  the  individual  programs  tested  in  module  reverification  win,  the  added 
requirement  that  the  full  interactive  system,  including  coaching  features,  be  on-line  and  was 
used  while  calling  the  various  programs  and  different  models. 

For  the  final  System  Test,  the  Utility  and  Static  Subsystems  were 
tested  using  SRI  workload.  The  Dynamic  Subsystem  was  tested  using  DSOl  and  2 workload  . 

The  acceptability  criteria  consisted  of  meeting  the  following  three  requirements: 

1 . The  results  of  the  System  Test  must  compare  favorably  with  the 
respective  program  or  model  test  results  derived  during  module 
reverification  . 

2.  The  Executive  Subsystem  must  function  correctly  and  every  pro- 
gram be  attainable  by  following  the  proper  calling  sequence. 

3.  The  system  must  properly  flag  the  user  when  a program  is  called 
and  the  required  files  or  specific  parameters  are  not  available 
for  use  by  the  program. 

All  program  results  compared  with  the  module  reverification  results, 
since  both  were  conducted  on  the  DEC  System-10. 

UTILITY  AND  STATIC  WORKLOAD 


Workload  Name 
SRI 

Workload  Name 
DSOl 
DS02 

4.  ACCEPTANCE  TEST 


Description  of  Workload 
A-7D 

Description  of  Workload 
User-Defined  Workload  (Model  DA) 
User-Defined  Workload  (Model  DBj 


This  test  remonstrated  that  MUXSIM  has  been  developed  with  the  capability  to 
accomplish  the  requirements  which  were  specified  in  the  amended  Statement  of  Work.  This 
test  consisted  of  a set  number  of  exercises,  experiments,  or  tests  intended  to  demonstrate  the 
various  capabilities  tha:  have  been  designed  into  the  system.  The  specific  tests,  objectives  of 
each  test,  a general  procedure,  and  acceptance  criteria  are  contained  in  the  MUXSIM  System 
Test  Plan  (Ref.  10,  Sec-ion  9). 
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The  specific  tests  ere  as  follows; 

a.  GASP  IV  (Test  1) 


b.  Load  Signal  List  (Data  Base),  Extract  and  Verify  Simulator  input,  and  Print 
the  Signal  List  (Test  2) 

c.  XT  Assignment  (Test  3) 

>'  Bus  Loading  versus  Bus  Command  and  Control  Schemes  (Test  4) 

e.  Bus  Loading  versus  Bus  Speed  (Test  5) 

f.  Controller  Loading  versus  Bus  Loading  (Test  6) 

g.  Message  Length  Limitations  versus  Bus  Loading  (Test  7) 

h.  impact  of  Command  and  Control  Uncertainties  on  the  Periodicity  of  the 
Fundamental  Update  Interval  Starts  (Test  8) 

i.  MUXSIM  Coaching  (Test  9) 

j.  MUXSIM  Installation  Test  (Test  10) 

k.  User  Demonstration 

5.  CONTINUAL  USAGE 

The  operation  or  continual  usage  phase  is  extremely  important  in  the  reverification 
and  usefulness  of  MUXSIM.  It  is  conjectured  that  there  will  be  several  levels  and  classifications 
of  users.  They  will  range  from  the  basic  user  to  the  more  advanced  users.  The  bosic  user  is 
someone  who  is  interested  in  learning  the  MUXSIM  system.  The  rapidity  of  his  progress  will 
serve  as  a measure  of  the  usefulness  of  the  Coached  Approach  to  the  Executive  System. 

Most  critical  to  this  verification  is  the  development  of  advanced  users,  or  those 
who  can  tie  MUXSIM  tc  an  actual  Multiplex  system  design  and  development  program,  or  througf 
using  MUXSIM  can  become  contributors  to  Multiplex  System  Technology. 

There  are  two  key  requirements  necessary  to  assure  continual  usage; 

1 . Application  of  MUXSIM  to  Multiplex  Design  and  Development  Program. 

2.  Aval  ability  of  the  training  necessary  to  encourage  the  development  of  advar- 
users 
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A MUXSIM  extension,  the  IDAMS7  Signal  List,  was  the  initial  step  of  an  effort 
pursuant  to  satisfying  the  first  requirement.  The  second  requirement  can  be  covered  by  course 
work,  some  of  which  is  already  available.  Table  B-V  lists  the  background  requirements  for  a 
user's  progression  upward  to  an  advanced  user . From  this  listing  are  extracted  the  recommenaa- 
tions  for  the  following  course  work 

• MUXSIM 

• GASP 

• TOPS- 10  (DEC  System-10  OS) 

The  simulator  operation,  conceivably,  may  also  be  supported  by  training  in  other  areas,  such 
as  communication,  digital,  and  computer  science  courses  to  broaden  the  user  Information  Transfer 
(Multiplex)  Systems  background.  These  courses  would,  of  course,  vary  according  to  the  user's 
intended  hardware  systems  application.  The  three  courses  mentioned  above  are  more  involved 
with  the  user's  skills  in  the  mechanics  of  using  MUXSIM. 

1.  MUXSIM 

Training  for  MUXSIM  may  be  conducted  at  several  levels,  due  to  the 
wide  variations  in  user  background.  A typical  family  of  stand-alone  packages  which  may  be 
offered  in  convenient  sessions  is  shown  in  Table  B-VI. 

2.  GASP 

GASP  (General  Activity  Simulation  Program)  is  widely  used  and  GASP  IV 
training  sessions  are  available  from  the  developer.  In  addition,  consulting  services  for  both 
training  and  developmental  assistance  are  available.  Information  regarding  GASP  training  may 
be  obtained  from: 

Pritskers  and  Associates 

1201  Wiley  Drive 

West  Lafayette,  Indiana  47906 

(317)  743-3287 

3.  TOPS-10 

TOPS-10  is  a well  developed  operating  system  and,  as  a result,  various 
levels  of  training  are  offered.  The  courses  are  generally  offered  at  the  supplier's  home  office. 
Information  regarding  TOPS-10  training  may  be  obtained  from: 


. Digital  Equipment  Corporation 

Software  Information  Services 

J Maynard,  Massachusetts  01754 


Table  B-V.  MUXSIM  USER  BACKGROUND  REQUIREMENTS 


Use- 
Mod  e 
No. 

Mode 

lies  . rip t ion 

Computer 
Background 
Requ i rements 

1 

Use  existing  Static 
Dynamic  Programs  and 
Work  loads 

General  understanding  of 
MUXSIM 

7 

Modify  existing  .'‘ta- 
ic  -i  Dynamic  Work- 
1 oau-- 

General  understanding  of 
MUXSIM 

3 

Add  new  MUXSIM  Static 
Workloads 

General  understanding  of 
MUXSIM 

4 

Modify  or  add  new 
Dynamic  Workloads 

General  understanding  of 
MUXSIM 

S 

Modify  existing 
Utility  or  Static 
Programs 

Knowledge  of  Fortran 

6 

Modify  Dynamic  Pro- 
grams 

Knowledge  of  GASP 

n 

1 

Add  new  Utility  or 
Static  Programs 

Knowledge  of  Fortran 

Knowledge  o(  MUXSIM 
Executive  details 

8 

Add  new  Dynamic 
Prog  rams 

Knowledge  of  GASP 

Knowledge  of  MUXSIM 
Executive  details 

5 

Modify  MUXSIM 
l.xecut  i ve 

Knowledge  cf  Fortran 

Knowledge  of  MUXSIM 
Executive  details 

Knowledge  of  DEC -10 
Operating  .System  (T0PS-1(V 

10 

Change  to  new  host 
compute r 

Knowledge  of  host  compu- 
ter architecture,  opera 
ting  system  configuration, 
MllX  S IM  rnach  i no  - dependent 
rout i ne s , and  MUXSIM 
software  partitionin'' 





Multiplex 
Background 
Requirements 

General  understanding 
of  multiplex  systems 


Knowledge  of  =pecific 
LRU's  being  changed 


Knowledge  of  periodic 
sampling  requirements 
for  Avionics  Suite 
Signals 

Knowledge  of  dynamic 
signalling  require- 
ments for  Avionics 
Suite  Signals 

Knowledge  of  the  data 
base  manipulation, 
multiplexing  design, 
periodic  sampling 
command  and  control 
techniques,  and  time 
line  analysis 

i 

Knowledge  of  the 
above,  plus  dvn.i:  . c 
command  and  cor.troi 
techn i quea 

Extensive  knowledge 
of  the  requirements 
for  modification  of' 
same  (see  5J,  plus 
knowledge  of  new  model.  I 

Extensive  knowledge 
of  the  requirements 
for  modification  of 
same  (see  C),  plus 
knowledge  of  new  model.  . 

I 

N/A 

i 
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Table  B-VI.  MUXSIM  USAGE  AND  APPLICATIONS  SEMINAR 


r 


15 


,■* 


I', 


CtfftR  ICtJI.lT^T 

INTRODUCTION 


, F I RST  DAY 

MUXSIM  Overview  with  emphasis  on  what  the  available  documentation 
covers . 

The  MUXSIM  Approach  and  a descript  ior.  of  each  subsystem. 

BASIC  USER 

Utility  Subsystem,  its  eight  (8)  programs  and  its  data  interface 
requirements . 

Static  Subsystem,  its  eleven  (11)  programs  and  its  data  interface 
requirements . 


SECOND  DAY 

GASP  TV  and  the  Dynamic  Subsystem,  its  two  (2)  programs  and  its 
data  interface  requi reroent s . 

Executive  Subsystem,  its  five  (5)  programs  and  its  data  interface 
requirements."  TffTYTlM  I n>  t a 1 i ,t  t ion  procedure. 

Demons trat i on  of  the  MUXSIM  coached  Structure,  MUXSIM  Installation, 
and  data  Base”  preparation  and  loading. 

Hands -on  execution  of  MUXSIM  Programs.  An  Open  Discussion  of  user 
needs  and  application: . 

ADVANCED  USER 


THIRD  DAY 

Overv iew  of  the  implementation  concept  for  new  or  more  detailed 
static  and  dynamic  models. 

Static  model  requirements,  how  to  determine  requ i rements  for  new 
static  models,  and  modeling  considerations. 

Formulating  techniques  for  evolving  or  creating  new  static  models. 

Utility  and  Executive  Impact,  new  model  impact  on  the  Utility  and 
Execut ive  subsystem . 


FOURTH  DAY 

GASP  iV  overview,  an  overview  of  GASP  [V  simulation  philosophy. 

GASP  IV  Programming  requirement  to  simulate  discrete  event  systems. 

Dynamic  model  requi rements , how  to  determine  requirements  for  new 
dynam ! c model  s arid  mode  I i ng  considerations. 

Pormul at i ng  techn  iques  for  evolving  or  creating  m w dynir  it  ; ode  I . 

FIFTH  DAY 

Demons t ration  of  Static  model  modifications.  Hands-on  experience. 
Demonstration  of  Dynamic  model  modification.  Hands-on  experience. 
Workshop  for  Static-dynamic  models. 

Open  Discussion  of  user  special  applications  and  general  evaluation 
of  how  MUXSIM  would  apply. 
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SECTION  VI 


SUMMARY  AND  CONCLUSIONS 


The  MUXSIM  development  cycle  consisted  of  a three-part  effort;  definition, 
design,  and  implementation.  This  Appendix  covers  the  implementation  phase.  It  repre- 
sents 54%  of  the  cost  and  52%  of  the  calendar  time  for  the  entire  program.  The  prime 
objective  during  the  implementation  phase  was  to  create  a MUXSIM  system  to  prove  the 
feasibility  and  usefulness  of  such  a tool. 

The  major  problem  solved  by  the  implementation  phase  was  that  of  software 
system  design  and  development  for  the  functional  design  of  Phase  II.  These  were  three 
key  decisions  during  the  implementation  phase:  1)  passing  the  programs  through  the  data 
and  progressive  file  creation;  2)  establishing  modularity  bounds  for  the  program  which  are 
related  to  hardware  functions,  thereby  facilitating  model  construction;  and  3)  the  tree 
structure  executive  and  handling  the  set  of  the  modular  programs  which  are  defined  to  a 
set  of  pseudo  batch  programs  called  sequentially  as  needed  by  the  user. 

The  use  of  GASP  IV  (1)  was  confirmed  to  be  the  correct  decision  by  the  effort 
during  the  program  nhase.  GASP  provides  a power  simulation  tool  constructed  in  an 
easy-to-use  manner  which  adds  versatility  to  MUXSIM. 

Originally,  the  intended  host  system  was  a PDP-11/45.  During  the  course 
of  the  development,  the  host  system  was  changed  to  a DEC  System-10.  The  result  was  a 
superior  host  system  which  greatly  enhanced  the  capabilities  and  potentials  of  MUXSIM. 

A secondary  result  was  that  the  modularization  and  job  scope  invoked  by  the  PDP-11/45 
remained,  thereby  assuring  the  success  of  the  implementation  phase. 

The  future  success  of  MUXSIM  depends  on  continual  use,  both  to  encourage 
its  growth  and  increase  its  versatility.  It  is  therefore  necessary  that  an  operation  phase 
should  follow,  which  will  shake  down  the  implementation  and  point  to  new  horizons  for 
improvements . 
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MUXSIM  TECHNICAL  NOTE  BIBLIOGRAPHY 


This  appendix  contains  a bibliography  of  selected  Technical  Notes  generated 
during  the  course  of  the  MUXSIM  program. 


Technical  Note 
Number 

2.2-01 

2.2-02 

2.5- 01 

2.5- 02 

2.4- 01 

2.4- 03 

6.0- 14A 

4.4- 01 

4.4- 04 

4.4- 05 

2.5- 05 

2.5- 09 

6.0- 04A 

6.0- 07 

6.0- 08 

6.0- 09 

6.0- 10 


Title 

DAlS  Hot  Bench  System  Definition 

CAS  DAIS  LRU  Configuration  Definition 

Caid  Coding  Requirements 

Traffic  Analysis  of  A-7D 

Derailed  Signal  Listing  Column  Headings 

Detailed  Signal  Listing 

DAIS  Utility  and  Data  Management  Routines 

DAIS  Multiplex  Data  Transfer 

DAIS  Message  Sequencing 

Message  Format  Modification 

A Technique  for  Minimizing  Data  Bus  Controller 
Message  Table  Pointer  Editing  Requirements 

Technique  for  Minimizing  Bus  Resource 

Utilization  on  DAIS  Scheduled  Data  Transfer 

DASIM1:  Description,  Status  and  Future  Plans 

DASIM6:  Subroutines  RDTRAF  and  WSORT 

DAS1M6:  Subroutine  WDMAP 

DASIM6:  Subroutine  MSGFLO 

DASIM7:  Subroutines  MREAD,  MSORT,  and 
TMELNE 
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Technical  Note 
Number 

6.0- 11 

6.0- 15 
2.5-06A 

6.0- 12 
5.1-02 

4.4- 13 

2.5- 08 

2.5- 07 

3.0- 01 

3.0- 02 

2.0- 01 

4.0- 01 

3.0- 03 

3.0- 04 

3.0- 05 

3.0- 06 

3.0- 07 

3.0- 08 

4.0- 02 


Title 
DAZiE  3 

Time  Line  Analysis 

CAS  DAIS  Bus  Traffic  Analysis 

Progress  with  GASP 

DAIS  Operability  Assessment 

ITS  Redundancy  Management 

Fault  Detection  and  Redundancy  Management 
Models  for  Simulation 

DAIS  Proposed  Traffic  Management  Scheme 

General  MUXSIM  Software  Organization 

MUXSIM  Executive  Program 

Technique  for  Using  Avionics  Suite  Data  by 
Nomenclature 

PDP-11/45  RSXIID  Operator  Input  Guide  for 
MUXSIM  at  WPAFAL 

General  Utility  Module  Requirements 

MUXSIM  Utility/Static  Module  System  Ops. 

MUXSIM  Program  Structure 

Utility  Module  Requirements 

Utility  Module  Programs 

Proposed  Header  Record  Format  for  All  Card/Tape/ 
Disc  Files  used  in  MUXSIM  Effort 

DECSYSTEM-10  User  Guide  for  MUXSIM  at 
WPAFAL 
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Technical  Note 
Number 

3.0- 09 

3.0- 10 

3.0- 11 

3.0- 12 

3.0- 13 

3.0- 14 

3.0- 15 

3.0- 16 

3.0- 17 

3.0- 18 

4.0- 03 

3.0- 19 

3.0- 20 

3.0- 21 

3.0- 22 


Note 

Extract  Word  Flow  Summary  (EXTWFS)  Program 
Definition 

Extract  Message  Flow  Summary  (EXTMFS) 

Program  Definition 

Computation  of  Bus  Loading  and  Utilization 
(COMBLU)  Program  Definition 

MUXSIM  Model  DA-A  Dynamic  MUXSIM  Model 
Which  Uses  Demand  Access 

MUXSIM  Model  DB-A  Dynamic  MUXSIM  Model 
Which  Uses  Redundancy  and  Fault  Management 

Static  Information  Grouping  and  Handling  (SIGH) 
Program 

Approach  for  Implementing  Static  Models  Using 
SIGH  Program 

Selection  Criteria  for  SFS  File  Record  Size 

MUXSIM  Integration  Nomenclature 

Binary  Matrix  Schedules  (TSCHDL)  Program 
Definition 

Standard  Program  Text  (MUXOPN)  Definition 

DECSYSTEM-10  Configuration 

Program  Hierarchy  Nomenclature 

Definition  of  TCONUP  and  TMSGLT 

AFAL  DEC-10  Physical  Data  Set  Definition 


Si , 
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